On Tue, 2014-10-14 at 18:09 +0200, Harald Schmalzbauer wrote:
> Bezüglich Ian Lepore's Nachricht vom 14.10.2014 17:37 (localtime):
> > 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?
> In general yes, that's what I did since my last ports-svn-update, but
> only to avoid complete breakage.
> Problem is that I have absolutely not in mind what OSVERSION on what
> machine to set. So I'm supplying a "dummy" version. That shouldn't be a
> problem for my purposes, but it's simply wrong. This check was
> introduced to gather the »correct« OSVERSION ;-) And manually supplying
> the correct version doesn't work due to brain contraints ;-)
> I like the idea to ask a userland installed indicator. But I'm not
> familar enough with bsd.incs.mk and the related installworld stage. I'd
> just need the hint from where include/Makefile gets conditionally
> (MK_TOOLCCHAIN!=no) included ... ?!? Somwhere it start's recursing the
> SUBDIRs, and I guess every binary calls installincludes: from it's
> directory (which works since bsd.lib.mk and bsd.prog.mk include
> bsd.incs.mk), but I can't find at what SUBDIR param.h is involved.
The old code that used to work for you got the version via sysctl, so I
was recommending that you keep doing that yourself, since it's no longer
built in to bsd.ports.mk.
So just add "export OSVERSION=`sysctl kern.osreldate` to your script
that kicks off this update process, something like that.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"