Conan: How to cause conan build to fail when pre-built package of existing binaries no available

[michaelmaguire]

I am packaging up an existing set of binaries (libs and headers) produced by another team.

The libs are available for several different profiles, and I publish those profiles to our internal Artifactory server.

I would like to ensure that when later builds are performed using unsupported profiles for which no pre-built binary packages are available, the build fails early with a clear error message.

Instead, what currently happens is that in our --build missing builds of a top level project we see:

bde-monolith/3.33.1.0@PORT/stable: WARN: This conanfile has no build step
bde-monolith/3.33.1.0@PORT/stable package(): WARN: No files in this package!
bde-monolith/3.33.1.0@PORT/stable: WARN: Lib folder doesn't exist, can't collect libraries: E:\nX\nX_nightlybuild\workspace\Conan_pipeline\.co\d34d8d\1\lib

but the build continues, and then later we get less clear error messages when headers from the missing package aren't found.

How can I ensure that for this recipe, any attempt to build it in the context of a --build missing build will fail explicitly?

I see:

@lasote commented on Apr 8

Hi! The canonical way to do that is raising ConanInvalidConfiguration exception at the configuremethod: https://docs.conan.io/en/latest/mastering/conditional.html?highlight=conaninvalidconfiguration#constrain-settings-and-options

The conan process with return 6 as a return code, so you can check in CI if you have to build that configuration or not.

https://github.com/conan-io/conan/issues/4924#issuecomment-480705882

But this is not what I'm looking for -- I don't want to add brittle logic to a def configure() method, I just don't want a "build from source" attempted for this package if the correct pre-built isn't found.

I have read:

https://docs.conan.io/en/latest/creating_packages/existing_binaries.html

but it doesn't seem to offer an approach to force a failure.

Can we support a:

build_policy = "never"

that would apply in the case of a --build missing build of a top level project that includes this package?

Obviously I would want the standalone create of this package to work when I'm performing the manual step of packaging up the existing binaries received from the other team.

https://docs.conan.io/en/1.9/mastering/policies.html

In absence of such a failure, is there a nice way within my recipe to detect the WARN: Lib folder doesn't exist, can't collect libraries error and fail at that point with a clear message?

To help us debug your issue please explain:

• [x] I've read the CONTRIBUTING guide.
• [x] I've specified the Conan version, operating system version and any tool that can be relevant.
• [x] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

Conan version 1.16.1 Windows Server 2012 R2

[Minimonium]

Hi, Michael, thanks for the detailed feedback. :slightly_smiling_face:
I see you have a "proprietary" or at least a "restricted" to build package. The current behaviour is as such because it's hard to recognize is the package empty as intended or not.
Your points are all on point (pun intended) and correct ways right now are:

1. Use configure() step or restricted settings in the recipe. It would fire an appropriate error message. It's the appropriate mechanism to signal that the recipe works only for a restricted set of settings. Why I think you should prefer it - is because it makes the recipe work with both developing and consuming workflows, you don't need to artificially separate that. Also, consider that without the source() step you would better be using exports on that one because otherwise, you spawn fragile recipes that require a lookup to the remote _every_ time. The idea is to cache for devs.
2. The existing_binaries part suggests using exceptions too since it's an appropriate mechanism for that.
3. You can try to play with Conan hooks. Make them part of your inner company-wide configuration. For example, post_package can check that a package is not empty and raise an error otherwise.
4. The option is a way too, but I'm not sure how it would behave if the user provides a policy themselves. Someone would correct me on that one, but I thought it replaces only the default behaviour, so it maybe would work a bit painfully with a never policy.

[michaelmaguire]

I tried the configure route:

    def configure(self):
        print("self.settings.compiler.toolset")
        print(type(self.settings.compiler.toolset))
        print(self.settings.compiler.toolset)
        if str(self.settings.compiler.toolset).endswith("_xp") :
            raise ConanInvalidConfiguration("This version of the package is not compatible with _xp toolset builds")

But I found that even my builds against a non _xp toolset it was failing:

conan_build_profiles[vs2015_14_v140_Debug,vs2015_14_v140_Release]
[...]
[Conan_pipeline] $ cmd.exe /C "conan info . --graph=dependency_graph.html && exit %%ERRORLEVEL%%"
conan_shared_python_requires/0.0.2@PORT/stable: Not found in local cache, looking in remotes...
conan_shared_python_requires/0.0.2@PORT/stable: Trying with '64808364-d686-4ba5-acd2-137e6df0e30d'...
Downloading conanmanifest.txt

Downloading conanfile.py
ERROR: bde-monolith/3.33.2.1@PORT/stable: Invalid configuration: This version of the package is not compatible with _xp toolset builds

[michaelmaguire]

Oh, wait!

I see that my jenkins job was failing before I even started my build -- the conan info call I before the build accepts a -pr profile (https://docs.conan.io/en/latest/reference/commands/consumer/info.html) and in this case requires the correct profile to be specified -- it was picking up my default which has v140_xp.

[lasote]

Hi @michaelmaguire. So your question is solved? Could this issue be closed? Thanks!

[michaelmaguire]

Closing. Thanks for the info.