Syslinux - Jan 2014 - Makefiles: includes and rule prerequisites

1) mk/syslinux.mk runs a shell to make a temp file gcc_ok.$$$$.tmp
(perhaps in the wrong directory) while several Makefiles have an
include rule for *.tmp which I believe is causing some occasional
parallel build issues.

make[3]: Entering directory `/home/gene/s/g/bios/memdump'
gcc_ok.6333.tmp:1: warning: NUL character seen; rest of line ignored
gcc_ok.6333.tmp:1: *** missing separator.  Stop.
make[3]: Leaving directory `/home/gene/s/g/bios/memdump'
make[2]: *** [memdump] Error 2


2) For recursive prerequisites, is it better to list the directory as
a prerequisite (simple and current approach) or would it be better to
have a more complex set of rules like the following:

--In com32/Makefile:
lib/libcom32.c32 lib/libcom32min.a lib/libcom32core.a: lib
libutil/libutil.c32: libutil

--In com32/rosh/Makefile:
rosh.c32: lib/libcom32.c32 libutil/libutil.c32

-- 
-Gene

Op 2014-01-18 om 15:58 schreef Gene Cumm:
> 1) mk/syslinux.mk runs a shell to make a temp file gcc_ok.$$$$.tmp
> (perhaps in the wrong directory) while several Makefiles have an
> include rule for *.tmp which I believe is causing some occasional
> parallel build issues.
> 
> make[3]: Entering directory `/home/gene/s/g/bios/memdump'
> gcc_ok.6333.tmp:1: warning: NUL character seen; rest of line ignored
> gcc_ok.6333.tmp:1: *** missing separator.  Stop.
> make[3]: Leaving directory `/home/gene/s/g/bios/memdump'
> make[2]: *** [memdump] Error 2
> 
> 
> 2) For recursive prerequisites, is it better to list the directory as
> a prerequisite (simple and current approach) or would it be better to
> have a more complex set of rules like the following:
> 
> --In com32/Makefile:
> lib/libcom32.c32 lib/libcom32min.a lib/libcom32core.a: lib
> libutil/libutil.c32: libutil
> 
> --In com32/rosh/Makefile:
> rosh.c32: lib/libcom32.c32 libutil/libutil.c32
> 
> -- 
> -Gene
Hello Gene,

I did get your observation, but I didn't get what you
are expecting from the mailinglist.

I do see that you are reporting two issues.
My suggestion is that you commit patches for issues
with what you think that is best.

I hope this helps ...

Groeten
Geert Stappers
-- 
Leven en laten leven

On Sat, Jan 18, 2014 at 5:00 PM, Geert Stappers <stappers at stappers.nl>
wrote:
> Hello Gene,
>
> I did get your observation, but I didn't get what you
> are expecting from the mailinglist.
To ask HPA, Matt Fleming and anyone else that may have more
experience/insight/background than I do.
> I do see that you are reporting two issues.
> My suggestion is that you commit patches for issues
> with what you think that is best.
Therein lies the issue: I'm not sure what the best solution is.  Why
were the the *.tmp files included in the first place?  Would it be
worth the effort to attempt the more complex dependencies?  I know
Matt took some effort at some point to put some of these dependencies
in and for com32, I just completed out some more today.

-- 
-Gene

On 01/18/2014 12:58 PM, Gene Cumm wrote:
> 1) mk/syslinux.mk runs a shell to make a temp file gcc_ok.$$$$.tmp
> (perhaps in the wrong directory) while several Makefiles have an
> include rule for *.tmp which I believe is causing some occasional
> parallel build issues.
> 
> make[3]: Entering directory `/home/gene/s/g/bios/memdump'
> gcc_ok.6333.tmp:1: warning: NUL character seen; rest of line ignored
> gcc_ok.6333.tmp:1: *** missing separator.  Stop.
> make[3]: Leaving directory `/home/gene/s/g/bios/memdump'
> make[2]: *** [memdump] Error 2
> 
Oops.  My bad.
> 
> 2) For recursive prerequisites, is it better to list the directory as
> a prerequisite (simple and current approach) or would it be better to
> have a more complex set of rules like the following:
> 
> --In com32/Makefile:
> lib/libcom32.c32 lib/libcom32min.a lib/libcom32core.a: lib
> libutil/libutil.c32: libutil
> 
> --In com32/rosh/Makefile:
> rosh.c32: lib/libcom32.c32 libutil/libutil.c32
> 
You *have* to use a PHONY target, e.g. the directory name.  Otherwise
you may end up with a dependency getting skipped simply due to the file
you test for existing since a previous build, it will then get rebuilt
later and all kinds of problems will happen.

	-hpa

On Sat, Jan 18, 2014 at 6:18 PM, H. Peter Anvin <hpa at zytor.com>
wrote:
> On 01/18/2014 12:58 PM, Gene Cumm wrote:
>> 1) mk/syslinux.mk runs a shell to make a temp file gcc_ok.$$$$.tmp
>> (perhaps in the wrong directory) while several Makefiles have an
>> include rule for *.tmp which I believe is causing some occasional
>> parallel build issues.
>>
>> make[3]: Entering directory `/home/gene/s/g/bios/memdump'
>> gcc_ok.6333.tmp:1: warning: NUL character seen; rest of line ignored
>> gcc_ok.6333.tmp:1: *** missing separator.  Stop.
>> make[3]: Leaving directory `/home/gene/s/g/bios/memdump'
>> make[2]: *** [memdump] Error 2
>>
>
> Oops.  My bad.
I wondered which was the error (the include or the gcc test rule)
>> 2) For recursive prerequisites, is it better to list the directory as
>> a prerequisite (simple and current approach) or would it be better to
>> have a more complex set of rules like the following:
>>
>> --In com32/Makefile:
>> lib/libcom32.c32 lib/libcom32min.a lib/libcom32core.a: lib
>> libutil/libutil.c32: libutil
>>
>> --In com32/rosh/Makefile:
>> rosh.c32: lib/libcom32.c32 libutil/libutil.c32
>>
>
> You *have* to use a PHONY target, e.g. the directory name.  Otherwise
> you may end up with a dependency getting skipped simply due to the file
> you test for existing since a previous build, it will then get rebuilt
> later and all kinds of problems will happen.
I wasn't questioning the first 10 lines to build the directories
recursively but the following lines of rules without recipes used to
resolve dependencies.  In other words, can things be structured to
work on building say %.o %.elf but stall buidling %.c32 until the
dependent libraries are finished.

Then again, it may just not be worth it.

-- 
-Gene