Closed obnyis closed 7 months ago
@obnyis Thank you for your report! We no longer build Debug in the CI due the small number of downloads and usually they result and the same build result as Release.
If I understand the case correctly, when building shared libraries in Debug, there is no suffix in the library file. Is that correct? If yes, I would say something is missing, because the Conan recipe for Poco does not change (neither CMakeToolchain) the debug postfix.
I built locally to be sure, and the build result is:
As you can see, the build generates the suffx d
to any library. So, what am I missing?
Hi @uilianries, thanks for replying.
I don't think I explained this too well initially, so I've created a minimum setup to reproduce the issue here:
https://github.com/obnyis/conan.poco.no_shared_library_debug_suffix
Our specific use case is an application that can load plugins dynamically, and we are using Poco as a framework to do this in a platform-independent way.
This behaviour doesn't have anything to do with Poco itself being a shared or static library. We are calling one of Poco's static functions to get the suffix, but it isn't matching with the libplugin.so
we end up with after a build.
@obnyis Thank you for providing such example and sorry the delay. It seems be a particular case, not related to Poco or the recipe. Usually, we only set definition that are exposed as CMake options, so we provide a package that's not only configurable, but also predictable in term of the upstream, by it's default behavior.
What you need to patch would change not only the package content, but also the default behavior of the library, so I really concerned about it, because it could break users.
What I would suggest is using a separated configuration to your case, where you can build the very same package, without affecting the current one.
The Conan config offers a way to inject compiler definitions, so it would solve your case:
https://docs.conan.io/2/reference/config_files/global_conf.html
tools.build:defines=["SHARED_LIBRARY_DEBUG_SUFFIX=1"]
You can add it to your Conan profile directly:
[settings]
...
[conf]
poco/*:tools.build:defines+=["SHARED_LIBRARY_DEBUG_SUFFIX=1"]
The only cons is that it will not affect the package ID.
Thanks for the feedback @uilianries, I'll give that a go and see if it will work correctly for us.
As an alternative for my pull request, would it be viable to add an "enable_no_shared_library_debug_suffix" in this case, defaulting to false and with the following section to remove it if build type isn't debug?
def config_options(self):
if self.settings.build_type != "debug":
del self.options.enable_no_shared_library_debug_suffix
@obnyis That would be acceptable yes. Could you please update your PR with such new option? Plus, let's keep it as False
by default, because in Poco there is no mechanism that pushes it as ON
, users need to pass the compiler definition directly.
@obnyis Sorry the confusion, but after talking with @jcar87 there is a second option that we think fits better for your particular case. As I mentioned before, using the configuration would not affect the package ID, but I totally forgot about that's possible to manage the package ID via Conan config too. So, in your Conan profile, you would need to add:
[conf]
poco/*:tools.build:defines+=["SHARED_LIBRARY_DEBUG_SUFFIX=1"]
poco/*:tools.info.package_id:confs=["tools.build:defines"]
You can see the full supported configuration in the Conan command config list: https://docs.conan.io/2/reference/commands/config.html#conan-config-list. You could add it to $CONAN_HOME/global.conf too.
To summarize, it will inject -DSHARED_LIBRARY_DEBUG_SUFFIX=1
in the compiler command line, and only for Poco, to any version. Plus, the package ID of Poco will take in account the content of the configuration tools.build:defines
, making it different from a regular package with same settings, options and dependencies.
Sorry again the delay and confusion, but as I mentioned before, your case seems be much particular, related to a runtime event, that is not generally used by consumers. Thank you for your time to explain your case and the PR.
I've had a change to review this and test this further. The proposed PR https://github.com/conan-io/conan-center-index/pull/22807 is probably fine.
@obnyis - please note that Conan does not change the library suffixes when creating packages, these come from the build scripts themselves. Some libraries use the d
suffix for Debug, some use _d
or _debug
, some libraries don't use any, and some libraries only do it on Windows but not on other platforms - so I think regardless of which option you go with when building poco, it unfortunately doesn't cover all cases if you use poco to derive the filename.
Please note that in your repro https://github.com/obnyis/conan.poco.no_shared_library_debug_suffix - passing -DCMAKE_DEBUG_POSTFIX=d
when building the plugin, would suffice - this can also be in the CMakeLists, you can find more examples: https://github.com/search?q=CMAKE_DEBUG_POSTFIX
However, given that this is a compile-time option for Poco, the PR itself is fine, even if we don't expect it to be generally used.
Hi @uilianries, @jcar87, thanks for the feedback on this.
@uilianries I like the general idea of package_id:confs
, but didn't find it able to do what we want for our internal recipes when applied to defines
. We have a few different profiles that are using include
to compose, and part of that is some defines that we need to ensure the entire dependency graph is built with for our security model. Having an additional line that appends defines for a specific recipe then brings up the question of what exactly will happen if something tries to reset the base defines afterwards.
For the following contrived example, what defines would poco end up with? I couldn't find any good source explaining how it would be handled.
[conf]
tools.build:defines=["MYDEF1=1" "MYDEF2"]
poco/*:tools.build:defines+=["SHARED_LIBRARY_DEBUG_SUFFIX=1"]
tools.build:defines=["MYDEF2"]
@jcar87 I agree that conan should not change the suffixes, and I am happy with that behaviour.
Yeah, I don't expect this to be generally used either, and I wish poco hadn't set this up as a compile-time option. We've added this to our internal conan-center-index as it works for us.
Description
With build_type=Debug specified in profile and building Poco and a shared library through conan, Poco::SharedLibrary::suffix() will return the incorrect platform-specific extension.
This is due to conan creating shared libraries without a ".d" to specify a debug version of a library as builds are separated into different folders.
For context see comment in the Poco header for this function: SharedLibrary.h:L115
My suggestion is to add
tc.preprocessor_definitions["POCO_NO_SHARED_LIBRARY_DEBUG_SUFFIX"] = "1"
into the recipe for poco. Should a new option for this behaviour be added as well, or should it be added for all builds?Package and Environment Details
Conan profile
[settings] arch=x86_64 build_type=Debug compiler=gcc compiler.cppstd=gnu17 compiler.libcxx=libstdc++11 compiler.version=13 os=Linux
Steps to reproduce
conan install -r poco/1.12.4
Logs
No logs, error is during runtime not build time