[Top][All Lists]

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

GNU make bugs reported in comp.unix.solaris

From: Paul Eggert
Subject: GNU make bugs reported in comp.unix.solaris
Date: Mon, 19 Mar 2001 05:32:19 -0800 (PST)

[I'm forwarding this message that was posted on comp.unix.solaris.]

From: address@hidden (Joerg Schilling)
Newsgroups: comp.unix.solaris,comp.unix.programmer
Subject: Re: GNU make --> Solaris make converter ?
Date: 17 Mar 2001 14:52:07 GMT
Organization: Technische Universitaet Berlin, Deutschland
Message-ID: <address@hidden>
References: <address@hidden> <address@hidden> <address@hidden>
NNTP-Posting-Host: fiesta.cs.tu-berlin.de

In article <address@hidden>,
Paul Eggert  <address@hidden> wrote:
>address@hidden (Joerg Schilling) writes:
>>      -       GNU make does not "make" >included<  make rule files
>>              and complains about nonexistent files
>>      -       GNU make then "makes" these files in the reverse order
>>              and even includes them in reverse (wrong) order.
>Could you give more details about the problem?

The best ides is to just try to compile cdrtools using gnu make.


Here is a short snipplet of the make log:

../RULES/r-gmake.dep:76: OBJ/i586-linux-cc/readcd.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/i586-linux-cc/cd_misc.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/i586-linux-cc/io.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/i586-linux-cc/scsi_cdr.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/i586-linux-cc/modes.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/i586-linux-cc/misc.d: No such file or directory
        ==> MAKING DIRECTORY "OBJ/i586-linux-cc"
        ==> MAKING DEPENDENCIES "OBJ/i586-linux-cc/misc.d"
        ==> MAKING DEPENDENCIES "OBJ/i586-linux-cc/modes.d"
        ==> MAKING DEPENDENCIES "OBJ/i586-linux-cc/scsi_cdr.d"
        ==> MAKING DEPENDENCIES "OBJ/i586-linux-cc/io.d"
        ==> MAKING DEPENDENCIES "OBJ/i586-linux-cc/cd_misc.d"
        ==> MAKING DEPENDENCIES "OBJ/i586-linux-cc/readcd.d"
        ==> COMPILING "OBJ/i586-linux-cc/readcd.o"
        ==> COMPILING "OBJ/i586-linux-cc/cd_misc.o"
        ==> COMPILING "OBJ/i586-linux-cc/io.o"
        ==> COMPILING "OBJ/i586-linux-cc/scsi_cdr.o"
        ==> COMPILING "OBJ/i586-linux-cc/modes.o"
        ==> COMPILING "OBJ/i586-linux-cc/misc.o"
        ==> LINKING "OBJ/i586-linux-cc/readcd"

Note that the 'No such file or directory' mesages are indicating the 
GNU make bug - not a bug in the makefiles.

>Hmm, isn't there a chicken-and-egg situation here?  If the included
>file contains rules or anything else that affects how to build the
>included file, I don't see how 'make' can build the file properly.

You are right, but you should carefully think about the problem.

-       If the rules in the to be included file affect the way this
        file has to be made than it is simply wrong.

-       If the to be included file contains rules that affect the
        decision whether to remake this file there is no problem.

        -       If the file does not yet exists, then there must be
                a bootstrap rule to allow creation.

        -       If the bootstrap rule already forces re-cretion
                we are done.

        -       If the rules inside the file tell us that we have
                to re-create it, we need to do this later.

Note that the main purpose for doing this is to create dependency rules (*).

GNU make re-execs itself in some cases toget around the problem
but this is not needed

...it can be solved as showm in my smake program:


by remaking the included files before the main tasks start.

>>      -       As GNU make copied the Sun idea of Pattern Matching
>>              Default Rules, GNU make will not honor the evaluation
>>              rules for precedence of these Rules.
>>              The result is to use the wrong default rules.
>Again, do you have an example, or a pointer to one?

$(ARCHDIR)/%.o:         %.c
                        $(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<

$(ARCHDIR)/%.o:         %.s
                        $(CAS) $(ASLAGS) $(CPPFLAGS) -o $@ $<

Will first look for a .c file and then for a .s file.
If you put each rule into a separate include rule file and the
order of include is reversed, then the order of precedence is
not as intended.


(*)     The gcc -MD option in principle could help but it is currently
        not usable. 

        It is currently in the state of a short sighted demonstrator
        version - not usable in real life.
        It seems that the Author did not really think about the problem
        when he decided to put the .d files into the same directory as
        the source file instead of using the same directory as for
        object files. This is needed as a decent compile envirentment
        allows simultaneous compilation (NFS mounted) on every supported

EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
      address@hidden            (uni)  If you don't have iso-8859-1
      address@hidden            (work) chars I am J"org Schilling
URL:  http://www.fokus.gmd.de/usr/schilling    ftp://ftp.fokus.gmd.de/pub/unix

reply via email to

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