Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Aug 1997 21:39:41 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        bde@zeta.org.au, reg@shale.csir.co.za
Cc:        current@freebsd.org
Subject:   Re: More bogons in Makefiles...
Message-ID:  <199708011139.VAA07673@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>> with a per-source directory obj symlink)).  Non sloppy makefiles would
>> use a more complicated search for the object directory that would
>> actually be used if `make' were run in the external source directory.
>
>An example being? ;) 

I don't know of any non-sloppy ones.  `make''s object directory search
path is too complicated to duplicate in dozens of Makefiles.  `make -V
.OBJDIR' was supposed to be useful for getting `make' to do the search,
but it has various problems including endless recursion and/or unacceptable
speed when used in complicated and/or large Makefiles.

>> There are more bogons here.  The whole ifdef is a verbose and confusing
>> way write `YEARISTYPE= ${.OBJDIR}/yearistype.  yearistype is always
>> created in the object directory and ${.OBJDIR} always exists (although
>> it's not clear where it is when make is invoked with args `obj all ...').
>
>>From this I read ${.OBJDIR} == ${.CURDIR} iff no 'make obj'. If that is

No, ${.OBJDIR} is the current directory for building sources.  yearistype
is always built there.  ${.CURDIR} is the current directory when `make'
is started.  yearistype is only built in ${.CURDIR} if ${.CURDIR} happens
to be the same directory as ${.OBJDIR} (I think it can be a different
path in some cases involving symlinks).

>correct then there is a lot of funny business going on, because there are a
>lot of checks this form.

Maybe.

>> Because I don't use it :-).  bsd.libnames.mk is no longer used in -current,
>> so this problem will go away automatically.
>
>Looks suspiciously like bsd.lib.mk includes this file... but now I'm lost ;)
>where do all the other defines for libraries come from? 

Nowhere.  Dependencies are generated by the _EXTRADEPEND target, and
${DPADD} is not used (except in bsd.kmod.mk), so none of the defines for
libraries are used.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708011139.VAA07673>