Re: installincludes, bsd.incs.mk and param.h

On Tue, 2014-10-14 at 17:24 +0200, Harald Schmalzbauer wrote:
> Bezüglich David Wolfskill's Nachricht vom 14.10.2014 16:52 (localtime):
> > On Tue, Oct 14, 2014 at 04:42:57PM +0200, Harald Schmalzbauer wrote:
> >>  Hello,
> >>
> >> since bsd.port.mk insinsts on param.h, I have inconveniences on my
> >> production systems which were installed with "WITHOUT_TOOLCHAIN=true" in
> >> src.conf (resulting in MK_TOOLCHAIN=no).
> >>
> >> My first attempt was the following patch:
> >> ...
> >> "$SYSDIR" makes the example above not working!
> >> Unfortunately I couldn't figure out when/how param.h gets installed.
> >> Also, I couldn't find out what stage uses include/Makefile, only that
> >> it's not used when  MK_TOOLCHAIN=no.
> >>
> >> Any help highly appreciated!
> >> ....
> > My production systems have their OS built on a "build machine"; at
> > install time, the build machine exports its /usr/src and /usr/obj, and I
> > "make installkernel installworld" (& mergemaster...) on the production
> > systems.
> >
> > I'm still building ports using portmaster on the production systems (as
> > I lack the infrastructure to create my own pkg repository, and I need
> > some non-default options), so I export the build machine's /usr/src &
> > /usr/obj to the production machines during the ports builds, as well.
> >
> > That said, I don't try to do anything with respect to MK_TOOLCHAIN -- in
> > normal use, the production machines don't have /usr/src or /usr/obj at
> > all anyway.
> >
> > In any case, this has generally been working for me for many years.
> 
> Sounds reasonable. For one (big) enivronment at least.
> I have different, completely unrelated environments which I maintain.
> Therefore I do have a complete project-oriented build- and rollout
> infrastruture, which also handles ports/packages (most times distributed
> as repository on CD, each CD a set of applications for one distinct
> machine).
> 
> So on my production systems, I don't need to (and even can't) compile
> any sources, but on some of them, I often use the ports tree for update
> checks or various - destination machine unrelated - tasks, like 'make
> fetch' for having a convenient way looking into sources e.g. ...
> The ports tree has been a very valuable source for me in many aspects,
> not just for compiling anything.
> 
> The param.h dependent OSVERSION check is relatively new, but bites me
> frequently. So I really need a possibility to make the ports tree usable
> again on machines which don't have any part of TOOLCHAIN installed.
> Preferably I'd like to "fix" the dependency as close as possible to the
> FreeBSD standard build environment, instead of botching post-installworld...
> 
> Thanks,
> 
> -Harry
> 
>  
> 

It appears that while bsd.ports.mk has lost the ability to use the
version of the running system (sysctl kern.osreldate), it still has the
logic to just use OSVERSION if it's already set on the make command line
or in the environment.  Can you leverage that to regain the behavior
you're used to?

-- Ian