tech-toolchain archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Make and makefile bugs (PRs 49085, 49086, 49087)
About the .NULL special target.
On Sun, Aug 10, 2014 at 07:02:40AM +0000, Christos Zoulas wrote:
> I thought this allowed you to do:
>
> .SUFFIXES: .gz
>
> .NULL.gz:
> gzip ${.ALLSRC}
>
> all: foo.gz
>
> but I see it does not work. But if you remove .NULL, how can you make it
> work?
I'm sorry but I do not understand what your example should do, therefore
I cannot answer your question.
Here is my understanding of the intended functionality of the .NULL
target. I've based this on "PMake - A tutorial" and the source code.
If anyone has actually ever used this feature, or for some other reason
knows exactly what this feature is for, please correct me if I'm wrong.
Here is an example makefile illustrating the feature, as it is
currently implemented.
.SUFFIXES: .c .out
.c.out:
cc -o $(.TARGET) $(.IMPSRC)
.NULL: .out
foo.c:
echo 'int main(void) { return 0; }' >foo.c
With this makefile, running "make foo" would result in the executable
foo being created with the .c.out rule. $(.TARGET) would be "foo"
instead of "foo.out" as it would normally be.
So, the syntax of the special target is
.NULL: .suf
where .suf is some suffix currently known suffix. There can only be one
null suffix at a time.
If a target is requested to be made, which does not have a suffix known
to make (foo in the example), it will try the transformation search
as if the file had the suffix specified by .NULL (foo.out). This
functionality is fully achieved with single suffix transformation rules
(e.g. you would use .c in the example), except that the suffix is not
faked.
Note that the functionality of .NULL is actually a subset of the single
suffix transformations. If you had the rules .a.b and .c.d, and files
foo.a and bar.c, you couldn't make both foo and bar with the same
makefile with .NULL only.
> I think that the most important feature missing in make is pattern
> rules; the whole suffix thing should be scrapped and implemented in terms
> of pattern rules. But that's a larger project.
I agree that make should have pattern rules.
I could work on more impromevements to make, including adding support
for pattern rules, if desired. While reading the code doing these
fixes, I came to conclusion that it could use some attention. There
seems to be a lot of duplication all over the place and no clear
separation of concerns between the modules. A proper high-level
overview of the code seems to be missing too.
So to not waste the effort I spent in getting to understand one slice of
the code, I think I could dig deeper and wider and document
the structure of the program. Then an extensive set of tests should
be made to cover the existing functionality, after which work on
improving the code and adding features could be done.
Would such work be a desirable contribution?
--
Jarmo Jaakkola
Home |
Main Index |
Thread Index |
Old Index