best way to tune ports to add a CLFAGS entry

[Julian Elischer]

On 29/06/2016 8:43 AM, Alfred Perlstein wrote:
>
>
> On 6/28/16 9:52 AM, Julian Elischer wrote:
>> At work I am doing various cross compiles in order to make a 
>> product under freebsd that actually will run under a modified 
>> FreeBSD that runs on an appliance. We want to get away from hand 
>> rolling everything to leverage all teh work in getting ports 
>> working well on FreeBSD.
>>
>> We have some extra syscalls and some structures have different 
>> sizes, so we need to compile/link agains an alternate set of 
>> includes/libraries and not those in /usr/include or /usr/lib.
>>
>> Ideally I want to use the "--sysroot" and "-isystem" options to the 
>> compiler/linker or failing that, add a -I or -L entries to make it 
>> look at the correct includes and libraries, not those in the base 
>> system.
>>
>>
>> In many ports CFLAGS etc. are sent in via the arguments to 
>> ./configure or environment vars, but there are many other ports 
>> that have other ways to specify these.
>>
>> Does the ports framework have any standard way to do this? 
>> LDEXTRA_ARGS or EXTRA_CFLAGS or similar?
>>
>> I've looked around and can't really see anything.  Best would be a 
>> single file to which I could add these things but adding them to 
>> the environment would also work.
>>
>> yours in ports ignorance..
>
> Sounds like a decent idea to override includedirs, but I wouldn't 
> trust it.  :)
>
> Why not do what NANOBSD/FreeNAS do and compile inside a chroot (or 
> even VM) with the proper includes and such installed?
we DO compile in a chroot. but that still requires that the local 
binaries use one set of .so files and the generated ones use a 
different set..
I do have ways around it.. like "rm -rf /usr/include/sys; ln -sfh 
/usr/product/sys/sys /usr/include/sys"
>
> It sounds like a big sledgehammer to use a chroot or a VM, but in 
> reality it's MUCH safer than some port accidentally pulling 
> something from the wrong /usr/include and then you spending hours, 
> days, etc tracking it down.  Trust me, I've seen the fallout and 
> it's NOT FUN!!!

oh I have too.. tha't why I'm using a chroot, bur we dont' want to 
generate a new chroot for every sub-point-release, and have to store 
it away forever, so I'm making the chroots be "semi permanent" which 
means that differences arize between them and the sources as we 
diverge, and before we build another chroot..

>
> For FreeNAS we made it so that you could run the FreeNAS OS (trueos) 
> as the actual build server and that saved us a huge number of 
> headaches.
>
yes I agree that would be nice but there are a large number of legacy 
issues at play so a cross-build style work flow is what I can get to.

> If you're very, very against the idea of VM or chroot then you could 
> just make /usr/include actually contain YOUR includes as you 
> probably shouldn't need them otherwise on a build server.
yeah I'm kind of doing that already.. IN the chroot..  wish I didn't 
have to. the chroot system binaries are pretty much -RELEASE binaries. 
but we use them to generare FOO-OS binaries which have to link to 
other .so files.
> -Alfred
>
>
>
>
> -Alfred
>