[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems with $(eval include...)
From: |
Paul D. Smith |
Subject: |
Re: problems with $(eval include...) |
Date: |
Sat, 28 Jun 2003 10:10:24 -0400 |
%% Fabio Alemagna <address@hidden> writes:
fa> On Fri, 27 Jun 2003, Paul D. Smith wrote:
fa> automake uses recursive makefiles, which is something I want to
fa> avoid.
>> I wasn't suggesting automake in total, I was suggesting their dependency
>> generation style only... this is basically what's described on my
>> website.
fa> hum... I must have got something wrong, then... Please, clarify
fa> this: does that method allow for proper handling of autogenerated
fa> files AND the usage of one single big makefile as opposed to
fa> multiple recursive makefiles?
Again, I'm not suggesting you use automake. Whether you can do
non-recursive builds using automake or not, I don't know.
I'm talking _only_ about the dependency generation, which is completely
unrelated to recursion.
>> The instant you want to start allowing parallel builds, which are
>> critical for today's software builds and for taking full advantage of
>> today's hardware, your method is no longer guaranteed to work.
fa> Isn't there any way to tell make to build exe-deps before any of
fa> the other prerequisites of exe, even with -jn, n > 1?
Sure. You specify that the other prerequisites also depend on exe-deps:
foo: exe-deps foo.o bar.o baz.o
foo.o bar.o baz.o: exe-deps
>> I thought you sent me an email saying that using the CVS source, it
>> worked?
fa> It works only in some situations, whilst in others it
fa> segfaults. I'm not quite sure which are those situations yet. I
fa> have to investigate further. There's one common behaviour,
fa> though: in any case, even if there's no segfault, if the file
fa> doesn't exist make doesn't invoke the rule to generate it, as it
fa> should instead do.
OK, please file a report as soon as you finish investigating.
fa> I'm sure I hit an "hidden" and not foreseen feature of $(eval),
fa> which should be supported though, so to be consistent with the
fa> general $(eval) semantics.
At this time I'm not prepared to agree with your comment "which should
be supported". I'll reserve judgment on that until I better understand
the problem and issues involved.
I will agree the core dump is unacceptable behavior, of course.
--
-------------------------------------------------------------------------------
Paul D. Smith <address@hidden> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
- Re: problems with $(eval include...), (continued)
- Re: problems with $(eval include...), Ted Stern, 2003/06/26
- Re: problems with $(eval include...), Paul D. Smith, 2003/06/27
- Re: problems with $(eval include...), Fabio Alemagna, 2003/06/26
- Re: problems with $(eval include...), Paul D. Smith, 2003/06/27
- Re: problems with $(eval include...), Fabio Alemagna, 2003/06/27
- Re: problems with $(eval include...), Paul D. Smith, 2003/06/27
- Re: problems with $(eval include...), Fabio Alemagna, 2003/06/28
- Re: problems with $(eval include...),
Paul D. Smith <=
- Re: problems with $(eval include...), Peter A. Kerzum, 2003/06/30
- Re: problems with $(eval include...), Paul D. Smith, 2003/06/30
- Re: problems with $(eval include...), Fabio Alemagna, 2003/06/30
Re: problems with $(eval include...), Fabio Alemagna, 2003/06/27