On Sat, 2022-06-25 at 17:47 -0400, Paul Smith wrote:
> This leaves me with two options:
>
> 1. Stop using gnulib, or at least sharply limit the modules we
> will include to those with trivial-enough configurations.
> 2. Abandon the build.sh script and require an existing make
> program in or
> On Jun 27, 2022, at 9:48 AM, Paul Smith wrote:
>
> As mentioned, the goal of "build.sh" is to allow systems without an
> already-existing make program to bootstrap themselves, by providing a
> way to build GNU make without using "make".
I think it's important that there be *a* way to rebuild
On Sun, 2022-06-26 at 22:00 -0400, Dmitry Goncharov wrote:
> What was the original driving force to introduce build.sh?
As mentioned, the goal of "build.sh" is to allow systems without an
already-existing make program to bootstrap themselves, by providing a
way to build GNU make without using "mak
On Sun, Jun 26, 2022 at 5:48 PM Paul Smith wrote:
> Seems like it's not so much that the patch was rejected; indeed they
> seem to agree there's a bug. But they wanted more work on it and it
> sort of fell apart. I have no idea how much effort it would be to push
> hard enough to get a change me
On Sunday, June 26, 2022, Paul Smith wrote
>
>
> I would prefer to have that fixed in gnulib, than continue to maintain
> a local copy just to avoid this issue.
Then there is no choice to drop gnulib and build.sh should go.
Since you asked for opinions, my opinion is that maintaining a mini make
On Sun, 2022-06-26 at 16:57 -0400, Dmitry Goncharov wrote:
> Have you considered to to avoid glob from gnulib? Make has its one
> impl of glob which it uses on certain systems.
> We could use this impl and maintain it on all systems.
While the original issue came up WRT glob, in actuality the prob
On Sun, Jun 26, 2022 at 10:11 AM Paul Smith wrote:
> This really came up because I was trying to find a way to include the
> latest gnulib globbing library. Adding "glob" to this pulls in a HUGE
> number of prerequisites.
Have you considered to to avoid glob from gnulib? Make has its one
impl of
Herring, Daniel - 0447 - MITLL wrote:
> On Jun 26, 2022, at 3:30 PM, Eli Zaretskii wrote:
>
> How do people bootstrap systems nowadays? Is it only via
> cross-compilation?
>
>
> Another way to bootstrap is to have a native tool chain that is less
> capable…. For example, an embedded device ma
On Jun 26, 2022, at 3:30 PM, Eli Zaretskii wrote:
How do people bootstrap systems nowadays? Is it only via
cross-compilation?
Another way to bootstrap is to have a native tool chain that is less capable….
For example, an embedded device may come with an old or proprietary shell and
compiler.
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Sun, 26 Jun 2022 15:06:36 -0400
>
> > No, I'm talking about not using Gnulib only for stage-1 build, the
> > one that produces a Make binary capable of building the full
> > version. I was not talking about avoiding to use Gnulib for the
> > fina
On Sun, 2022-06-26 at 17:39 +0300, Eli Zaretskii wrote:
> > The problem is that the process for "make-less" systems in the past
> > has been: run configure, then run build.sh. But we won't be able
> > to use the environment created by configure in this "new" build.sh,
> > because it works in tande
> From: Paul Smith
> Date: Sun, 26 Jun 2022 10:11:12 -0400
>
> > Can you list the Gnulib functions we currently use?
>
> You can find them in the bootstrap.conf file:
>
> https://git.savannah.gnu.org/cgit/make.git/tree/bootstrap.conf
>
> See the list at the end.
OK, thanks. The list is very
On Sun, 2022-06-26 at 07:34 +0100, Sven C. Dack wrote:
> 3. Allow to build a minimal Make executable, which provides basic and
> traditional Make functionality and does not rely on gnulib, and then
> use it as a bootstrap.
It's certainly a possibility. But there is already so much ifdef etc.
in G
On Sun, 2022-06-26 at 08:41 +0300, Eli Zaretskii wrote:
> It is sad that Gnulib maintainers aren't prepared to cater to a GNU
> project, and an important one such as Make. These are special
> requirements that only a handful of GNU project could ever have, and
> for good reasons, so supporting the
On Sun, 2022-06-26 at 02:14 +0200, Henrik Carlqvist wrote:
> Would this "old version of make" have to be GNU make?
It would need to be some version of make that is supported by automake.
As far as I'm aware, automake-generated makefiles are currently
intended to run with any POSIX-compliant vers
The obvious end-point of #2 is to add a make-4.3.tar.gz file to future make
packages and modify build.sh to unpack and use it. This might involve renaming
the "inner" script to "build-4.3.sh" or similar.
But I also have the same question: what are the real-world cases where build.sh
is needed?
On Sat, Jun 25, 2022 at 12:48 PM Paul Smith wrote:
> I'm trying to decide what the future is for GNU make's "build.sh"
> bootstrapping script. As you may recall, this script is provided to
> allow GNU make to build on systems which don't already have an instance
> of make installed. Its goal is t
Hello,
developers causing a "Catch 22" paradox is not new. You want to avoid
such software, or at least work around it with a big margin. Sharply
limiting the use of gnulib here may not provide such a margin and cause
repeated trouble in the future. Your condition of "to those with
trivial-enough
> From: Paul Smith
> Date: Sat, 25 Jun 2022 17:47:47 -0400
>
> I had a discussion about this with the Gnulib maintainers a while ago:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2019-09/msg00041.html
>
> However the gnulib maintainers were disinclined to modify the practices
> of the gnul
On Sat, 25 Jun 2022 15:28:52 -0800
Britton Kerin wrote:
> On Sat, Jun 25, 2022, 1:48 PM Paul Smith wrote:
> > If #2 is chosen, then a bootstrap process would involve first obtaining
> > an older version of make, such as GNU make 4.3 or lower, and building
> > that with its build.sh, then using t
On Sat, Jun 25, 2022, 1:48 PM Paul Smith wrote:
> I'm trying to decide what the future is for GNU make's "build.sh"
> bootstrapping script. As you may recall, this script is provided to
> allow GNU make to build on systems which don't already have an instance
> of make installed. Its goal is to b
I'm trying to decide what the future is for GNU make's "build.sh"
bootstrapping script. As you may recall, this script is provided to
allow GNU make to build on systems which don't already have an instance
of make installed. Its goal is to build the first make binary, without
of course all the fanc
22 matches
Mail list logo
