[bug] bazel generator not usable for packages with multiple libs, like openssl

[a4z]

Environment Details

• Operating System+version: All
• Compiler+version: Not relevant
• Conan version: All
• Python version: All

Steps to reproduce

Use the bazel generator and use libcurl on Linux in your project, so it depends on openssl.
libcurl will not be usable in your bazel project, since libcrypto.a and libssl.a appear in the wrong order for the linker

Solution

To make the order work, the alwayslink = True attribute should be set on the cc_import libs

So this:

cc_import(
    name = "ssl_precompiled",
    static_library = "lib/libssl.a",
)

cc_import(
    name = "crypto_precompiled",
    static_library = "lib/libcrypto.a",
)

should look like that

cc_import(
    name = "ssl_precompiled",
    static_library = "lib/libssl.a",
    alwayslink = True,
)

cc_import(
    name = "crypto_precompiled",
    static_library = "lib/libcrypto.a",
    alwayslink = True,
)

in the generated BUILD file for openssl

we can also discuss if it would not make sense to set visibility = ["//visibility:public"], on the cc_import part, since there are use cases where users use only libcrypto , but not libssl from openssl, but that might be a different issue

[a4z]

The alwayslink option has of course the disadvantage that it will blow up the size from the consumer

But I have no idea how that could be solved otherwise, since we do not know the required order of the libs.

It could be an option to make the cc_import visibility public, then consumers can create their own version of a cc_library, and have the library just exporting the interface, but that is also complicated.

With alwayslink, the recipes can at least be used ...

[a4z]

additional info: conan writes the order of libraries correct,
I am not sure if that happens on purpose or by accident, but that does not matter in that context.

anyhow, the reason why I have the problem:
since I use the packages in a multi platform scenario, I need to re-write some names, like, openssl -> openssl_armv8

this happens with buildozer

unfortunately, buildozer uses buildifier to format the BUILD file, and that flips the order
I can not find out how to prevent that from happen, see bazelbuild/buildtools#1073

shall I change the PR so it adds a # do not sort comment on the right position, so buildifier does not touch the deps order ?
sorting can also happen when you have your editor configured to automatically run buildifier on files, like I do it in some projects , and we have even a CI rule, that BUILD files need to be buildifier conform.

so maybe adding the comment would be a good idea, what do you think, @czoido ?

[czoido]

Hi @a4z,
I was also double checking that the order was correct, yes, we sort the components before writing the deps in the generator files. I could not reproduce because I did not use buildozer for my tests, but now the problem seems clear.
Does only adding the # do not sort comment (but without alwayslink = True) fix the issue for you? If that's true I think we could just add that comment to prevent this to happen for people using this tool.

[a4z]

yes, the #do not sort on the right position does prevent buildifier from sorting array entries
I updated the PR

[czoido]

yes, the #do not sort on the right position does prevent buildifier from sorting array entries I updated the PR

Great, I'll mark this for the next release. Thanks for the contribution.