bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #35485] New $(.MFDIR) built-in variable


From: Tim Murphy
Subject: Re: [bug #35485] New $(.MFDIR) built-in variable
Date: Thu, 9 Feb 2012 17:25:55 +0000

That "resetting MAKEFILE_LIST" trick is the thing is what works for us
- I should have said that's what we had to do (although more crudely)
instead of making you write out the solution :-).  I just have this
feeling that it's a bit of a "sharp corner" in make when doing
non-recursive makefiles and I wish I could think of a neat way to
solve it whilst still being able to get the current makefile name and
any parent makefiles in the recursive case.

I also think that it can be expensive to append things onto very long
lists in make but that's just suspicion and I really need to take a
proper look at it instead of making accusations.

I think that getting the directory of the current makefile is useful
although I am sure my team have had trouble with  $(abspath) and the
way it works in some situations on windows (unfortunately our stuff
has to work on both)  - it was something to do with which drive letter
got stuck on to a relative path (e.g. off the CWD)  to make it
absolute and this possibly not always being the drive letter you
wanted.  Again this is unsubstantiated since my emails about that are
stuck in some old Lotus notes database.

Regards,

Tim

On 9 February 2012 14:37, David Boyce <address@hidden> wrote:
> On Thu, Feb 9, 2012 at 5:33 AM, Tim Murphy <address@hidden> wrote:
>> Hi,
>>
>> I know this is tangential, but:
>>
>> MAKEFILE_LIST itself is a problem for non-recursive builds because it
>> gets very big if you have a lot of include statements (as opposed to a
>> gigantic single makefile file).
>
> True, but apparently there's no restriction against modifying it as
> the makefile below shows, so might it be viable to truncate it at
> strategic locations as shown?
>
> A smaller fix within make would be to normalize all paths in the list
> relative to CURDIR, which never changes within the make process.
> Currently pathnames ar recorded as used, which means you can get a mix
> of absolute and relative and non-canonical names like
> ../../lib/libfoo/../../cmd/blah.mk. Absolute paths in particular can
> get quite long. But this is unlikely to happen - have you tried
> simplifying as below?
>
> -David Boyce
>
> ========================================
>
> include MFa
> include MFb
> include MFc
> include MFa
> include MFb
> include MFc
> include MFa
> include MFb
> include MFc
> include MFa
> include MFb
> include MFc
> MAKEFILE_LIST := $(firstword $(MAKEFILE_LIST)) $(lastword $(MAKEFILE_LIST))
> include MFa
> include MFb
> include MFc
>
> $(info MAKEFILE_LIST=$(MAKEFILE_LIST))
>
> all: ;



-- 
You could help some brave and decent people to have access to
uncensored news by making a donation at:

http://www.thezimbabwean.co.uk/friends/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]