mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Christian Melki <christian.melki@t2data.com>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] RFC: Make version selection.
Date: Sun, 20 Jun 2021 07:45:39 +0200	[thread overview]
Message-ID: <0dece245-050e-4334-0fdf-73b5ec14f0db@t2data.com> (raw)
In-Reply-To: <20210619214446.pra4s3tyan4tshi6@pengutronix.de>

On 6/19/21 11:44 PM, Roland Hieber wrote:
> On Fri, Jun 18, 2021 at 02:29:07PM +0200, Christian Melki wrote:
>> Make 4.3 introduced a new set of incompatibility.
>>
>> https://lwn.net/Articles/810071/
>>
>> This rarely affects building, but sometimes it will.
>> How about adding something like tool version selection?
>> (Building a specific version perhaps?).
>> Ptxdist seem rather content with just "some make", but since host version
>> will undeniably affect the build success in some cases, how about making it
>> an option?
>> Host cmake is a host-rule f.ex?
> 
> This could result in a bit of yak shaving, because PTXdist host tools
> are built using the normal PTXdist build system, which first feeds all
> rule files to make and uses it for dependency generation. So make would
> still be needed on the host to build the new host-make.
> 

Sure. It will need a real host make, regardless.
But can't this be done like a ... host-make-old? Then your make variable
for that obnoxious package gets treated with a "older make" and the rest
of the world lives on like normal?
Ptxdist doesn't care, neither does the vast majority of packages. They
are going to be up to date and have fixed makefiles.

> As an alternative, we could invent a special way to build the host-make
> first (could be a static shell library function), and then restart
> parsing the rules with the new host-make. But still then, at least one
> make is needed on the build host to build PTXdist itself after the
> ./configure … :)
> 
Yuck. :)

> As another alternative, we could test for known make incompatibilities
> on PTXdist startup and try to set up our rule files accordingly so they
> built with all make versions. Maybe add a linter function too, if
> possible.
> 

I got stuck on the new make with the really, really old gstreamer tools.
I've patched them (will send those in if anybody cares). So keeping up
with patches is also an alternative. But I'd rather be able to tell
ptxdist "older make here please".

>  - Roland
> 


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de

  reply	other threads:[~2021-06-20  5:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-18 12:29 Christian Melki
2021-06-19 21:44 ` Roland Hieber
2021-06-20  5:45   ` Christian Melki [this message]
2021-06-25  7:50     ` Michael Olbrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0dece245-050e-4334-0fdf-73b5ec14f0db@t2data.com \
    --to=christian.melki@t2data.com \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox