> On Jun 22, 2023, at 5:39 PM, David Boyce wrote:
>
> > DIR := $(shell pwd)
>
> My only contribution to this is to point out that I believe the above
> construct, while very common, is unnecessary. The $(CURDIR) variable is
> defined by the manual to be an absolute path to the current worki
> DIR := $(shell pwd)
My only contribution to this is to point out that I believe the above
construct, while very common, is unnecessary. The $(CURDIR) variable is
defined by the manual to be an absolute path to the current working
directory of the make process. Combined with the fact that make ha
On Sun, 2023-06-11 at 12:29 +, Zoltán Turányi wrote:
>> Couldn’t these be handled by creating a "namespace" concept for
>> rules? One could merge 2 Makefiles by prefixing each target with the
>> directory of the Makefile. This would make dir1/all different from
>> dir2/all. Also in recipes vari
On Sun, 2023-06-11 at 12:29 +, Zoltán Turányi wrote:
> My problem is that contrary to the make wisdom of writing a single
> Makefile (to which I agree) most projects are still divided into
> parts with separate build definitions. One can debate if this is good
> or bad - for me it is a requirem
Thanks Paul, and also to the others, who have responded to this idea.
My problem is that contrary to the make wisdom of writing a single Makefile (to
which I agree) most projects are still divided into parts with separate build
definitions. One can debate if this is good or bad - for me it is a
On Tue, 2023-05-23 at 09:13 +, Zoltán Turányi wrote:
> So here is the idea. What if a subsequent invocation of make (in a
> subdir)– instead of building the target it is given – would just
> parse the makefile, create a full ruleset internally and inject this
> ruleset into the parent make’s ru
On Tue, May 23, 2023 at 9:07 AM Zoltán Turányi
wrote:
> If we invoke make on the top makefile, it will compile the two lib{1,2}.o
> object files serially.
That's because your rule is
subs:
cd sub1
make
cd ../sub2
make
Do something lik
> On May 24, 2023, at 2:37 AM, Zoltán Turányi
> wrote:
>
> Hi David,
>
> Thanks for your informative response, comments and references.
>
> I do see your point (and in a way wanted to attack the separation of the DAG
> myself with this topic).
> However, the advice to place all make inform
Subject: Re: new feature idea: ingesting processed rulesets
>
> On Tue, 23 May 2023 12:07:51 -0400
> "David A. Wheeler" wrote:
>> The solution is to *NOT* use recursive make. Have *ONE* process run
>> the makefile, with the correct data. Now you can enable par
>
> On Tue, 23 May 2023 12:07:51 -0400
> "David A. Wheeler" wrote:
>> The solution is to *NOT* use recursive make. Have *ONE* process run the
>> makefile, with the correct data. Now you can enable parallel jobs, and have
>> it run really quickly, because the make process has the correct infor
> > On May 23, 2023, at 5:13 AM, Zoltán Turányi
> > wrote:
> > I use make with autotools in multiple directories and have observed that
> > parallel builds are limited to each directory, as autotools invoked make
> > separately for each directory.
In my experience, if make is called recursively
> On May 23, 2023, at 5:13 AM, Zoltán Turányi
> wrote:
>
> Hello,
>
> I have looked through the mail archives and the manual (to some degree of
> thoroughness) and have not found this idea yet. If, it exists, I apologize
> for the spam in advance.
>
> I use make with autotools in multip
Hello,
I have looked through the mail archives and the manual (to some degree of
thoroughness) and have not found this idea yet. If, it exists, I apologize for
the spam in advance.
I use make with autotools in multiple directories and have observed that
parallel builds are limited to each dire
13 matches
Mail list logo
