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. > > Thanks, > > -Harry > 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. -- IanReceived on Tue Oct 14 2014 - 15:00:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:52 UTC