how to add local changes to buildworld?

Daniel Braniss danny at cs.huji.ac.il
Wed Mar 28 16:05:09 UTC 2018



> On 28 Mar 2018, at 17:39, Ian Lepore <ian at freebsd.org> wrote:
> 
> On Wed, 2018-03-28 at 08:50 +0300, Daniel Braniss wrote:
>> 
>>> 
>>> On 27 Mar 2018, at 19:47, Ian Lepore <ian at freebsd.org> wrote:
>>> 
>>> On Tue, 2018-03-27 at 19:20 +0300, Daniel Braniss wrote:
>>>> 
>>>> Hi,
>>>> I have some local additions which int the past, after making changes
>>>> to some Makefiles, etc, I got them compiled
>>>> but somehow, things stopped working after 11, so I’m now trying to do
>>>> a fresh set of patches,
>>>> and was wondering if there is some docs around on how to to this
>>>> cleanly? trying to figure out the *.mk is becoming a bit complicated.
>>>> thanks,
>>>> 	danny
>>>> 
>>> If you're asking what I think (you want to add code of your own into
>>> the buildworld), just add LOCAL_DIRS="path/to/dir1 path/to/dir2" to the
>>> buildworld command line and it will visit your directories and run the
>>> same targets there as for standard freebsd dirs (so your makefiles have
>>> to have those targets, mostly easily accomplished by including the
>>> usual bsd..mk where foo=prog|lib|subdir|whatever.
>>> 
>>> The local dir paths in LOCAL_DIRS must be relative to the top-level
>>> freebsd source dir, you can't use absolute paths (but you can use
>>> relative paths that take you outside the freebsd path, I think, like
>>> ../mysources/project1).
>>> 
>>> -- Ian
>>> 
>> I guess in my haste I was not clear enough :-)
>> my problem is the dependency,
>> in particular, it’s a pam module, that needs a local library. in the past the library was compiled first, and then the module,
>> now it still happens, but the module does not find the library, which has been compiled! there is a new piece of mail that
>> i’m missing :-( 
>> i’ll try again with LOCAL_DIRS.
>> thanks
>> 	danny
> 
> Oh yeah, libraries... there is also a LOCAL_LIB_DIRS you can set to
> list libraries.  But looking at Makefile.inc1 it builds the local lib
> dirs after the other local dirs, which seems completely wrong and
> useless.  I think the LOCAL_LIB_DIRS should be built along with the
> base system dirs; the attached patch would do that.
> 
> -- Ian
> Index: Makefile.inc1
> ===================================================================
> --- Makefile.inc1	(revision 331499)
> +++ Makefile.inc1	(working copy)
> @@ -241,6 +241,17 @@ X${BINUTIL}?=	${${BINUTIL}}
> SUBDIR=	${SUBDIR_OVERRIDE}
> .else
> SUBDIR=	lib libexec
> +# Add LOCAL_LIB_DIRS, but only if they will not be picked up as a SUBDIR
> +# of a LOCAL_DIRS directory.  This allows LOCAL_DIRS=foo and
> +# LOCAL_LIB_DIRS=foo/lib to behave as expected.
> +.for _DIR in ${LOCAL_DIRS:M*/} ${LOCAL_DIRS:N*/:S|$|/|}
> +_REDUNDANT_LIB_DIRS+=    ${LOCAL_LIB_DIRS:M${_DIR}*}
> +.endfor
> +.for _DIR in ${LOCAL_LIB_DIRS}
> +.if ${_DIR} == ".WAIT" || (empty(_REDUNDANT_LIB_DIRS:M${_DIR}) && exists(${.CURDIR}/${_DIR}/Makefile))
> +SUBDIR+=	${_DIR}
> +.endif
> +.endfor
> .if !defined(NO_ROOT) && (make(installworld) || make(install))
> # Ensure libraries are installed before progressing.
> SUBDIR+=.WAIT
> @@ -282,17 +293,6 @@ SUBDIR+=contrib/ofed
> SUBDIR+=	${_DIR}
> .endif
> .endfor
> -# Add LOCAL_LIB_DIRS, but only if they will not be picked up as a SUBDIR
> -# of a LOCAL_DIRS directory.  This allows LOCAL_DIRS=foo and
> -# LOCAL_LIB_DIRS=foo/lib to behave as expected.
> -.for _DIR in ${LOCAL_DIRS:M*/} ${LOCAL_DIRS:N*/:S|$|/|}
> -_REDUNDANT_LIB_DIRS+=    ${LOCAL_LIB_DIRS:M${_DIR}*}
> -.endfor
> -.for _DIR in ${LOCAL_LIB_DIRS}
> -.if ${_DIR} == ".WAIT" || (empty(_REDUNDANT_LIB_DIRS:M${_DIR}) && exists(${.CURDIR}/${_DIR}/Makefile))
> -SUBDIR+=	${_DIR}
> -.endif
> -.endfor
> 
> # We must do etc/ last as it hooks into building the man whatis file
> # by calling 'makedb' in share/man.  This is only relevant for


i also found LOCAL_LIB_DIRS, and the library was built, but then when I tried to use it with
LIBADD += idng
it complained it didn’t know what I was talking, so I had to add it to bsd.libnames.mk and bsd.own.mk
which is sort of messy.
BTW, the order of the libs in my case was not important, as long as they got compiled before the pam module!

anyways, now I have changed my old method (dates back to 4!) and switched to use mercurial + svn, and
hopefully will be able to track my local changes better - though I’m still figuring out how to do this :-)

thanks,
	danny



More information about the freebsd-hackers mailing list