Conan-center-index: [question] Policy regarding tools.collect_libs(self)

[danimtb]

Comming from https://github.com/conan-io/conan-center-index/pull/278/files#r341819980

@SSE4 said:

in general, I'd avoid usage of it. tools.collect_libs returns alpha-numeric sorted list of libraries withing self.cpp_info.libdirs. it might be undesired in several cases:

there are libraries which shouldn't be linked by default (e.g. preloadable_libiconv.so in case of libiconv
there are more than just one library within the directories, and linking order is important (e.g. project is not Windows-only)
in these cases the result of tools.collect_libs is not the expected and intended one. for bzip2 it might be harmless (e.g. there is only one library), but in generic case it causes troubles.

I would like to open a discussion about it here to get a policy added to the wiki

cc/ @Croydon @madebr @memsharded @jgsogo

[madebr]

I agree on disallowing tools.collect_libs() when the number of libs in self.cpp_info.libs is greater then 1.

[jgsogo]

An additional problem related to tools.collect_libs(): you need to actually build the library to populate self.cpp_info.libs... so you cannot evaluate package_info() before building it and it may block some possible parallelization (I'd need to think if there is any parallelization possible affected by this).

So my vote would be: no tools.collect_libs() at all 🤷‍♂

[Croydon]

Libraries often have different names based on if they are shared/static release/debug and sometimes even based on compilers and operating system or similar information (yes, in the name, not in the file ending). Handling this certainly would mean more (annoying) detail work with if .. else blocks.

People might also not know immediately what the final names are for configurations they don't use and the CI doesn't test for, which might cause more bugs for consumers.

[madebr]

Do the CI hooks test whether the libs in collect_libs are actually in the package?

[ericLemanissier]

I agree on disallowing tools.collect_libs() when the number of libs in self.cpp_info.libs is greater then 1.

+1

An additional problem related to tools.collect_libs(): you need to actually build the library to populate self.cpp_info.libs... so you cannot evaluate package_info() before building it and it may block some possible parallelization (I'd need to think if there is any parallelization possible affected by this).

So my vote would be: no tools.collect_libs() at all 🤷‍♂

AFAIU, all the information returned by package_info is useful only for consumption of an existing binary, and this information is useless if the binary does not exist yet, so I don't see how it could block some parallelization.

Do the CI hooks test whether the libs in collect_libs are actually in the package?

I'm not sure I understand what the purpose of such hook would be. if collect_libs returns libraries which are not in the package, then it's a bug in conan, not in the recipe. This kind of bug should be covered in conan's unit tests, not in a hook. Also, isn't the purpose of test_package to make sure that all self.cpp_info.libs can be linked ?

In the end, I think the best would be to deprecate tools.collect_libs(), and create tools.collect_lib() which does the same, but thows/warns if 0 or more than 1 library is found.

[uilianries]

I see no problem using tools.collect_libs(). Only few cases caused problem and we needed to use a manual lib list. Also, some project can vary the libraries names from version to version, resulting in more conditionals in middle of the recipe to list or not a library name, depending the version.

[Morwenn]

Manual lists become more tedious to handle when there is a growing list of dependencies that might change depending on the option (yeah, I just spent two days with that kind of problem). It would be handy if Conan had a way to use tools.collect_libs() and to just tell the linker to use --start-group and --end-group if possible - that wouldn't always make the recipes better but having the latter option would at least make them more robust resilient to version and option changes wrt link issues 🤔

But this would be a design issue more than a policy issue. With tools.collect_libs() in its current form I would say that it might warrant a warning if it's used with more than one lib because it's easy enough to forget about link order.