Created attachment 217085 [details]
poudirere testport log for audio/libsndfile with TEST=ON
Ports including audio/libsamplerate, audio/pulseaudio and audio/twolame depend on the shared library libsndfile.so, installed by audio/libsndfile.
However, with STATIC=ON, audio/libsndfile instead produces the static library libsndfile.a.
Setting TEST=ON also sets STATIC=ON, I believe due to the following line in the Makefile:
This means that libsndfile.so is not available for dependent ports. I have attached poudriere testport logs for audio/libsndfile with TEST=ON and for an example dependent port audio/libsamplerate.
In my humble opinion, enabling testing during the port build should not break compatibility with dependent ports. Can testing be achieved in a different way?
For now, the workaround is to build with TEST=OFF.
Created attachment 217086 [details]
poudriere testport log for dependent port audio/libsamplerate (failing)
Unfortunately the only supported variant is by using static compiles so there isn't much you can do at ports level. If you want to pursue upstream to fix this feel free to do so otherwise I'd consider this as a "won't fix" issue.
As TEST is off by default, a warning that it will break dependent ports would be a reasonable thing to do. It's only a problem if TEST is explicitly turned on.
I don't see working around the ports framework viable and not doing unit tests is a bad idea in terms of stability and regression so we're basically down to a limited choice of "solutions":
1, List as "broken" unless STATIC is selected if you have TEST enabled
2, Keep it as is, there's no way we can safeguard options for ports in general and we have a lot of ports containing options that would break dependent ports.
3, Submit a patch upstream fixing this issue
I opted for option 2 as it requires little interaction and TEST isn't enabled by default however if you have a better solution please attach a patch.
(In reply to daniel.engberg.lists from comment #4)
A pkg-message in the TEST=on case to inform the user about the implications so as to improve UX and reduce support (such as this issue), is probably the btest bet until a more permanent solution/resolution can be identified, likely upstream
Addressed in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248665
Created attachment 217270 [details]
With the following diff, changing the build to use the recommended (by upstream) autotools build system, provides both static and shared libraries, and tests pass
During QA a number of other issues were identitied (for example, if sqlite is installed for unrelated reasons, its detected by the build and links against it, along with Makefile simpliciation and a number or ports compliance issues rectified
libsndfile doesn't recieve much development these days and for the last years pretty much everything has gone into cmake rather than autotools hence my decision to change it (and the documentation hasn't recieved updates in years). I can fix sqllite dep and seeing that many projects are moving away from cmake I also think its valuable to have the cmake config files available as many users appears to move away from autotools. This also seems to the trend looking at other package repos fwiw.
I think we should not overcomplicate things here. It would be good to have the build-time tests, but switching to the legacy build system for it does not seem like the best tradeoff. I would like to get this addressed properly upstream, and created https://github.com/libsndfile/libsndfile/issues/684 to track it.
Closing this WAI for now.
Thanks, Thomas. I agree that it makes sense to consider this is an upstream issue, even if looking at the initial reply to your report (at https://github.com/libsndfile/libsndfile/issues/684) it seems unlikely to changed.