Re: [bug #35485] New $(.MFDIR) built-in variable
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). Regards, Tim On 8 February 2012 18:30, David Boyce invalid.nore...@gnu.org wrote: URL: http://savannah.gnu.org/bugs/?35485 Summary: New $(.MFDIR) built-in variable Project: make Submitted by: boyski Submitted on: Wed 08 Feb 2012 06:30:41 PM GMT Severity: 3 - Normal Item Group: Enhancement Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: CVS Operating System: Any Fixed Release: None Triage Status: None ___ Details: The attached one-line (plus docs) patch adds a .MFDIR variable which evaluates to the directory of the containing makefile, more or less. It's actually just shorthand: diff -u -r1.60 default.c --- default.c 16 Jan 2012 02:29:22 - 1.60 +++ default.c 8 Feb 2012 17:45:49 - @@ -527,6 +527,7 @@ #endif #endif /* !VMS */ + .MFDIR, $(abspath $(dir $(lastword $(MAKEFILE_LIST, 0, 0 }; Justification: though this adds no new functionality, I think it's important for support of non-recursive build styles. Given a build tree with many directories containing source files and makefiles, in a recursive model the tendency is to cd into each directory and invoke make locally, and thus the important relative directory is the cwd aka $(CURDIR). But in a flat build model those sub-makefiles tend to be included into a single make process and CURDIR doesn't change. In this case the important relationship is with the directory containing the controlling sub-makefile. Currently the playing field is tilted towards cwd-centric builds by the support for CURDIR. Having .MFDIR would even that out by making it easier to think in terms of a makefile-relative directory. Expecting naive (or even expert) developers to qualify paths with $(abspath $(dir $(lastword $(MAKEFILE_LIST is a nonstarter. This could be made more verbose as MAKEFILE_DIR or less as MWD. The leading . is just my guess as to what would be most compatible. Also, it's arguable whether this is better handled as a regular predefined variable, subject to removal with -R, or a hard-wired variable analogous to CURDIR. ___ File Attachments: --- Date: Wed 08 Feb 2012 06:30:41 PM GMT Name: mfdir.diff Size: 2kB By: boyski http://savannah.gnu.org/bugs/download.php?file_id=25027 ___ Reply to this item at: http://savannah.gnu.org/bugs/?35485 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make -- 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/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #35485] New $(.MFDIR) built-in variable
On Thu, Feb 9, 2012 at 5:33 AM, Tim Murphy tnmur...@gmail.com 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: ; ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #35493] Provide access to existing platform type data via a builtin variable
URL: http://savannah.gnu.org/bugs/?35493 Summary: Provide access to existing platform type data via a builtin variable Project: make Submitted by: boyski Submitted on: Thu 09 Feb 2012 05:08:57 PM GMT Severity: 3 - Normal Item Group: Enhancement Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: CVS Operating System: None Fixed Release: None Triage Status: None ___ Details: There are thousands of makefiles containing logic like this uname := $(shell uname -s) # or worse, = ifneq (,$(filter Linux,$(uname))) LINUX_HOST := 1 else ifneq (,$(filter CYGWIN%,$(uname))) CYGWIN_HOST := 1 else ... endif This is complicated, duplicative, hard to read, has portability issues due to relying on a Unix utility, etc. Meanwhile make already contains a variable make_host describing the platform it was built for, and a one-line patch can make it available within makefiles: define_variable_cname (MAKE_HOST_TYPE, make_host, o_default, 0); The attached patch also includes documentation. ___ File Attachments: --- Date: Thu 09 Feb 2012 05:08:57 PM GMT Name: make_host.diff Size: 2kB By: boyski http://savannah.gnu.org/bugs/download.php?file_id=25038 ___ Reply to this item at: http://savannah.gnu.org/bugs/?35493 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #35485] New $(.MFDIR) built-in variable
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 david.s.bo...@gmail.com wrote: On Thu, Feb 9, 2012 at 5:33 AM, Tim Murphy tnmur...@gmail.com 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/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #35485] New $(.MFDIR) built-in variable
Follow-up Comment #1, bug #35485 (project make): T Murphy says: 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. This is unsubstantiated since my emails about that are stuck in some old Lotus notes database. To which I say: A. There will be such corner cases. I have a similar one with Cygwin where we must use cygpath -a -m instead of $(abspath) to translate Unix pathnames into Windows style. But with that said, it's no worse having a shorthand. If abspath is broken on Windows you need to hack around it either way, or fix it in make. B. It might be better to use realpath instead of abspath. The differences I know of are that the path must exist and symlinks are resolved. In this case the directory is already known to exist and resolving symlinks might be a feature. C. As noted, it's possible to implement this directly in C code instead which might help work around issues with abspath. D. Of course if abspath itself is really broken WRT drive letters then that should be fixed, but that's outside scope here. ___ Reply to this item at: http://savannah.gnu.org/bugs/?35485 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
