There's much contention over whether to include /usr/local in the include paths.
This poll is designed to judge how popular the notion is.
It is open to everybody to participate.
There's four choices:
- Yes. We always do it. There's no way to avoid it short of hacking the code.
- Yes, we do it when MK_INCLUDE_USR_LOCAL is "yes" and it defaults to yes.
- Yes, we do it when MK_INCLUDE_USR_LOCAL is "yes" and it defaults to no.
- No. Keep the status quo (only way to change it is to hack the code)
This poll is for the base system. It is my belief that ports should follow whatever
we decide here, but if there's contention, there will be another poll for that.
Note: /usr/local would be used for the entire toolchain, but libraries and includes. The 'INCLUDE' in the straw man name is intended in the 'add it to the path' sense not to imply just -I include processing.
Note 2: It's understood that '/usr/local' is just a shorthand way to speak of LOCALBASE and any implementation would likely take that into account.
Note 3: Options 2 and 3 are present to allow companies with local build systems to opt-out of the /usr/local additions easily. The advantage to the projects is they won't have to carry patches to do this. The disadvantage is that more ports people will have to test on two systems (those build with the option, and those built without) and that will be such a substantial burden that only the default will get tested and the non-default will be perpetually broken.
You can find a preliminary write up of all the issues covered in the comments here.
Event Timeline
Some thoughts: maybe the toolchain should "do the right things" if LOCALBASE is defined?
Also, it'd be nice if there was an opt-out so host paths don't pollute the build too much (sometimes upstreams do bad things with header names).
Note that this MK_FOO logic is incompatible with upstream, obviously. They will probably not want a FreeBSD-specific CMake option for this stuff. So if people are really that attached to /usr/local/include, it should be added uncondionally.
Btw, I'm not voting here, since I like to maintain neutral about this. :)
Installing ports into /usr isn't this vote. Don't assume that will or won't happen when voting. It is a completely separate (and more contentious) issue.
I'd rather have compilers built out of ports include /usr/${LOCALBASE}/include and base's CC (clang, gcc, whatever) not include /usr/${LOCALBASE}/include. Also, what about /usr/local/lib? It seems that including /usr/local/include is only part of the problem - you can compile but not link? If we think folks are savvy enough to add /usr/local/lib to their library path, but not savvy enough to add /usr/local/include to their include path, that seems to be in conflict.
/usr/local/lib would be added to the library path, as well as /usr/local/include to the include path. the INCLUDE in the option name I put up as the straw man name is in the sense of 'add these to the path' not 'just do include processing' so would include whatever is needed in the toolchain to produce consistent results.
updated wording of poll to include this an an earlier clarification I posted to the comments...
As the ports clang maintainer I'm fine with either 1 or 4, but don't want anything to do with 2 or 3. I'm weakly leaning toward 1, but not enough to sign up to do more than change the default in the various clang ports.
I said Yes, but I think that we need to clean up our base libraries first. We need to make most/all libs private. If it isn't part of posix, it needs a man page which links to functions provided.
If the clean up is not done before the change, then my vote is No.
It's not clear to me how this proposed change (option 1) would affect building base from source. It seems we would want a way to turn off /usr/local/{include,lib} when building src, probably off by default. It seems option 1 precludes turning it off for source builds.
It's also not clear how base will be packaged and built. There has been talk of /private in the past. Would there be a package base-private-cctools and no general/developer CC by default? Wouldn't it make sense to turn on /usr/${LOCALBASE} for ports first, see how base gets packaged, then decide whether it is necessary to turn it for base-cctools?
Option 1 doesn't turn off /usr/local/include. It will always be in the list when /usr/include is in the list. However, we already turn off /usr/include when building from source, so I don't understand the concern.
Since we don't need to turn it off, we'd presumably build the packages in Bapt's new pkg base the same way. I'm not sure I understand the comment about building ports first. Can you explain it more?
Ahh, thanks for the clarification re src builds and turning off /usr/include. WRT ports, I meant to turn on including /usr/${LOCALBASE} for port builds first, see what the fallouts are and address/fix the issues, then turn it on for base CC. But since I was under the wrong impression with regard to building src, I withdraw my comment about applying the change to port builds first before base CC. Sorry for the noise :-(
I want to vote strongly against MK_INCLUDE_USR_LOCAL. Requiring port maintainers to test their ports with this option both on and off is not workable and neither is dealing with bug reports where users may or may not have changed this setting.
When building base, we explicitly override the system include and linker paths, so this change will not affect things. When building ports, we explicitly add LOCALBASE to the compiler paths. Obviously, both should be tested carefully with a patched compiler to test.
Paths provided on the command line take precedence over paths provided by the defaults (defaults are, after all, intended to be easy to override).
The only thing that will change if /usr/local/{include,lib} are in the default header / library search paths is that, for a use that has not explicitly built their own packages with a non-standard LOCALBASE, the following sequence will actually work:
$ sudo pkg install libfoo $ cc src_using_libfoo.c -lfoo $ ./a.out
Currently, this sequence will first die complaining that it can't find libfoo.h (or whatever the header is), then die when the linker can't find libfoo.so. The same sequence (adjusted to use the host platform's equivalent of pkg install) does work on OS X (even with third-party package managers), and with most Linux distros. I think it also works on OpenBSD, but I haven't had an OpenBSD machine to test on for a while.
We explicitly add /usr/local/lib to rtld's search path, but we don't add it to the default search path for static linking, which is horribly inconsistent (there is no other path on the system where I must explicitly pass -L to the linker, but where rtld will then find the shared library without -rpath or LD_LIBRARY_PATH being set).
On the order question, other platforms place /usr/local before /usr, which makes it easy to override base system components. If I have installed OpenSSL from packages, for example, then I probably want to be compiling / linking against this version and not the one in base. This behaviour can be overridden by explicitly passing -I/usr/include -L/usr/lib, if it is not intended (this will search /usr first, but fall back to /usr/local if things are not found.
I don't fully grok/know the (purported or claimed) advantages/disadvantages of options 2 and 3, nor how doing this in base provides benefits different from, or on top of doing it for, in, or only in the ports framework
If someone (@imp?) can update the poll description with some short benefits/potential downsides of each, it would help provide context that may enable more people to understand and cast an informed opinion.
I've done this for years in a proprietary product based on FreeBSD and can't imagine going back. The ill effects are few and mostly easy to diagnose, being only about as strange as the things you encounter when you're pretty sure /usr/local is in the search path, but it turns out that it isn't for obscure reasons. Or when badly-behaved configure scripts, etc., won't let you add it. While I sort of morn the loss of more strange BSD conservatism, this is such an obvious reality that I cannot possibly bring myself to tolerate the idea that we should keep going. Users should not have to care about how things were in the mid '90s. An increasing number of them weren't even born yet. System compilers search the default location of local additions and packages.
I'd like to understand why those that voted No and Yes did so.
What is the one argument that 'seals the deal' for you?
One short summary bullet point only please.
What is the one argument that 'seals the deal' for you?
[ For voting yes ]
Having spent far too much of the last 15 years helping non-FreeBSD developers work around this and trying to persuade them that, if they get past the stage of 'FreeBSD can't even find libraries that it installed,' the system has enough positive attributes that they should spend time learning it.
Yes. However, the build needs to only look in /usr/include or better yet the source tree with --sysroot. It can not accidentally be reading /usr/local/include during buildworld.
Also, if we're going this route we should seriously consider making the same change to other facilities, such as the default PATH and cron PATH, LD_LIBRARY_PATH, etc.