Rework privatelibs, it now renamed the libs a libprivate${LIB}
If it installs headers they are automatically installed in usr/include/private/${LIB}
Use libucl as an example
Automatically defines LIB${LIB} for PRIVATELIBS in src.libnames.mk
Keep the regular name in LIBADD to allow to promote PRIVATELIBS into regular libs without having to rework all Makefiles listing it
Details
Details
- Reviewers
brooks imp des bdrewery - Commits
- rS282420: Rework PRIVATELIB
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage
Event Timeline
Comment Actions
The changes look good to me.
| ObsoleteFiles.inc | ||
|---|---|---|
| 65 | Seems to duplicate the second half of the above list. | |
Comment Actions
Can you please explain the reasoning behind renaming the libraries themselves? I created PRIVATELIBS precisely to avoid having to do that.
Comment Actions
What is the issues of PRIVATELIB:
any application linking to a library from base (a regular one) that does itself
links to a PRIVATELIB cannot anymore statically link to the said application.
There is no mechanism to handle PRIVATELIBS in compat*x ports which can be a
problem if one of our regular lib is linked to a privatelib and ends up into
compat one day.
It prevents easy linking for 3rd party application using those privatelibs on
purpose (aka with the knowledge abi can break) like libbsdstat.
Comment Actions
Also notes, that when packaging base current PRIVATLIB implementation results in exposing the libraries in private as provided (provide libucl) which theory can be satisfied by something ports will provide while with the new mechanism it will provide libprivateucl which prevents having to add new hacks in pkg
@des is that ok with you?