Change Details

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: 1) Yes. We always do it. There's no way to avoid it short of hacking the code. 2) Yes, we do it when MK_INCLUDE_USR_LOCAL is "yes" and it defaults to yes. 3) Yes, we do it when MK_INCLUDE_USR_LOCAL is "yes" and it defaults to no. 4) 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.

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: 1) Yes. We always do it. There's no way to avoid it short of hacking the code. 2) Yes, we do it when MK_INCLUDE_USR_LOCAL is "yes" and it defaults to yes. 3) Yes, we do it when MK_INCLUDE_USR_LOCAL is "yes" and it defaults to no. 4) 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 [[ https://wiki.freebsd.org/WarnerLosh/UsrLocal | preliminary write up ]] of all the issues covered in the comments here.

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: 1) Yes. We always do it. There's no way to avoid it short of hacking the code. 2) Yes, we do it when MK_INCLUDE_USR_LOCAL is "yes" and it defaults to yes. 3) Yes, we do it when MK_INCLUDE_USR_LOCAL is "yes" and it defaults to no. 4) 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 [[ https://wiki.freebsd.org/WarnerLosh/UsrLocal | preliminary write up ]] of all the issues covered in the comments here.