On May 7, 2013, at 10:09 PM, Warner Losh <i...@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 <yaneg...@gmail.com> wrote:
>> 
>> On Tue, May 7, 2013 at 2:00 PM, Warner Losh <i...@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
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Reply via email to