[RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree

Garrett Cooper yanegomi at gmail.com
Wed May 8 05:39:25 UTC 2013


On May 7, 2013, at 10:09 PM, Warner Losh <imp at bsdimp.com> wrote:

> 
> On May 7, 2013, at 9:42 PM, Garrett Cooper wrote:
> 
>> On Tue, May 7, 2013 at 2:26 PM, Garrett Cooper <yanegomi at gmail.com> wrote:
>> 
>> On Tue, May 7, 2013 at 2:00 PM, Warner Losh <imp at bsdimp.com> wrote:
>> 
>> On May 7, 2013, at 2:46 PM, Garrett Cooper wrote:
>> 
>>> On May 7, 2013, at 1:39 PM, Brooks Davis wrote:
>>> 
>>>> On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote:
>>>>> Hi,
>>>>>  A common pattern that I've seen at Isilon and something else that I've
>>>>> wanted to have for a while is the ability to designate where the top of a
>>>>> source tree was. This is important and helpful when dealing with source
>>>>> files that build upon each other or depend on sources located in other
>>>>> sections of the tree; contrib stuff needs to set .PATH appropriately to
>>>>> point to sources at the top of the tree, sys stuff is riddled with S= in
>>>>> order to point to where /sys, etc lives, we build upon FreeBSD within an
>>>>> expected directory structure as well.
>>>>>  I haven't come up with a name, but was wondering if this was a good
>>>>> idea, and if so does anyone have any outstanding patches for this that can
>>>>> be pushed into FreeBSD?
>>>> 
>>>> I'd like to see this.  There's a variable for this in NetBSD and I've
>>>> wanted to do this because it makes code easier to relocate within the
>>>> tree.
>>> 
>>>      This is another good reason. It would make porting code to/from NetBSD a LOT easier… especially because I plan on pulling a lot of test/test infrastructure code from NetBSD and I really don't want to commit too many local changes to the Makefiles. Less divergence -> better cross-pollination -> less work for all -> win for the BSDs.
>>>      Thanks for the reminder.. I'll base it off what NetBSD did :).
>> 
>> SRCDIR
>> 
>> EVARINUSE?
>> 
>> share/mk/bsd.doc.mk:# SRCDIR    Directory where source files live.  [${.CURDIR}]
>> share/mk/bsd.doc.mk:TRFLAGS+=   -I${SRCDIR}
>> share/mk/bsd.doc.mk:.PATH: ${.CURDIR} ${SRCDIR}
>> share/mk/bsd.doc.mk:    cd ${SRCDIR}; \
>> share/mk/bsd.doc.mk:SRCDIR?=    ${.CURDIR}
>> share/mk/bsd.doc.mk:    cd ${SRCDIR}; ${UNROFF} ${MACROS} ${UNROFFFLAGS} \
>> share/mk/bsd.doc.mk:    cd ${SRCDIR}; ${UNROFF} -ms ${UNROFFFLAGS} \
>> share/mk/bsd.info.mk:SRCDIR?=   ${.CURDIR}
>> ...
>> share/doc/llvm/Makefile:SRCDIR=         ${.CURDIR}/../../../contrib/llvm
>> share/doc/llvm/Makefile:.PATH: ${SRCDIR} ${SRCDIR}/lib/Support
>> share/doc/llvm/clang/Makefile:SRCDIR=           ${.CURDIR}/../../../../contrib/llvm/tools/clang
>> share/doc/llvm/clang/Makefile:.PATH: ${SRCDIR}
>> 
>> Once upon a time, this *HAD* to be set, and wasn't inferred from the current top of the tree. Please, for the love of god, make sure that we don't lose the infer from top of tree ability, or I will hurt you. Often. Through all the minions that owe me minor favors.
>> 
>> I don't want to break that ever; it's a fantastic feature. If you could point me to where that magic awesomeness lives (make?), I'll be more than happy to address it in my branch where I'm going to do this.
>> 
>> I really don't like how NetBSD turned their top-level build command into a shell script [in part because it needs to bootstrap a bunch of tools]. It makes things painful when doing iterative builds..
>> 
>> So all in all, I completely and wholeheartedly agree with your concerns.
>> 
>> Oh sweet.. this is something to keep in mind too (from bsd.port.mk)...
>> 
>> # SRC_BASE      - The root of the src tree.  (Some ports require this to get
>> #                 kernel sources).  Default: /usr/src
>> 
>> All else fails, ports has done it first -_-...
>> 
>> Not the first var I've seen this done with...
> 
> I thought ports specifically named things differently to avoid conflicts.

Perhaps. It matches autoconf too. It's just a pain when there isn't consistency, but oh well...
Thanks!
-Garrett


More information about the freebsd-arch mailing list