Conan packaging

[friendlyanon]

Hey there.

I need to package this utility in order to properly include Firebird SQL in Conan. Current pending PR: conan-io/conan-center-index#8951

Some things are missing though. The IDPL license is not in this repository and it appears some fields ought to be filled in it by the author. Additionally, this utility is not versioned. It would be nice to have this project versioned for better UX.

Packaging for Conan is also why #7 was opened. CMake trivializes building this utility across all platforms.

[asfernandes]

I like conan and cmake!

But why you need to package this as cloop is also present in Firebird tree and is built together?

[friendlyanon]

Vendoring prevents proper dependency tracking. The CMake model also does not really support building and using tools in a single build. I recently assisted the SerenityOS project to move away from that model, because it always kept breaking their builds. Now they build host and target platform projects separately and this does not break builds.

The goal would be similar here. Patch FirebirdSQL, so it uses the compiled dependencies from Conan instead of the shipped precompiled and source dependencies.

[friendlyanon]

Totally off-topic, but do you know by chance how actively maintained version 3 of FirebirdSQL is? That is the version that is distributed on windows.php.net and so I wish to package that for Conan, because my goal would be to eventually make PHP use CMake to build and Conan to get its dependencies as well.
It would be very nice if the FirebirdSQL project didn't do funky stuff in its CMake build scripts and stuck to the idiomatic dependency discovery mechanism, i.e. find_package. Naturally, I can be of help in that regard.

[friendlyanon]

Just to increase your sample size of people saying that vendoring is not ideal, I can recommend this conference talk if you have the time to spare: https://www.youtube.com/watch?v=NSemlYagjIU
It's got a bit of humor in it as well, so it's worth taking a look at just for the entertainment value.

[AlexPeshkoff]

On 1/18/22 00:24, friendlyanon wrote: Totally off-topic, but do you know by chance how actively maintained version 3 of FirebirdSQL is?

Currently it's still maintained but recommended for new development is definitely version 4.

[asfernandes]

There are various obstacles from what you want:

• Firebird does need to build and then use some tools
• It does have cmake scripts, but they are unmaintained and are very complicated. So it was a one man contributor thing, not adopted by core team
• cloop from Firebird diverges a lot from one of this repository, unfortunately
• You'd have hard times trying to convince people to download dependencies (even when they are cached) rather than have them in the same repository

In some personal projects, I'm adopting the conan/cmake approach and liking it.

[friendlyanon]

Firebird does need to build and then use some tools

How is cloop used in the FIrebird build process then? I have not looked deeply into the build code.

It does have cmake scripts, but they are unmaintained and are very complicated. So it was a one man contributor thing, not adopted by core team

Unfortunate. I could help with getting things into shape if necessary.

cloop from Firebird diverges a lot from one of this repository, unfortunately

Any reason for this divergence?

You'd have hard times trying to convince people to download dependencies (even when they are cached) rather than have them in the same repository

The build process is already abstracted with the use of additional scripts. Dependency acquisition and invoking CMake with the paths of those dependencies can be done in the scripts transparently. People who don't want to deal with extra stuff will be non the wiser and those who want control over their builds can do anything with CMake.

[friendlyanon]

@asfernandes Ping. I would like to know what the situation here is regarding cloop and FirebirdSQL. cloop is a build requirement to generate source files, which means that it must not and cannot be built in the same build as FirebirdSQL, because that would break for cross-compile use-cases.

[AlexPeshkoff]

On 1/30/22 18:46, friendlyanon wrote: @asfernandes <https://github.com/asfernandes> Ping. I would like to know what the situation here is regarding cloop and FirebirdSQL. cloop is a build requirement to generate source files, which means that it must not and cannot be built in the same build as FirebirdSQL, because that would break for cross-compile use-cases.

Not provided cloop is built for build host, not target. That's how android build works.

[friendlyanon]

What does that mean? The 3.x tarball contains cloop only as source code. That must be built to be used for source generation.

[AlexPeshkoff]

On 1/30/22 19:35, friendlyanon wrote: What does that mean? The 3.x tarball contains cloop only as source code. That must be built to be used for source generation.

It's built & used during firebird build process. But it's not needed for regular (not firebird dev) operation. Therefore (like some other such utilities) it's not included in binary package.

[friendlyanon]

Oh, so cloop is a developer only build requirement. Actually, what are the normal dependencies of FirebirdSQL? https://www.firebirdsql.org/en/building-the-code/ and linked pages do not say anything about what the dependencies are.

[asfernandes]

Oh, so cloop is a developer only build requirement. Actually, what are the normal dependencies of FirebirdSQL? https://www.firebirdsql.org/en/building-the-code/ and linked pages do not say anything about what the dependencies are.

Please use firebird-devel list for these questions - https://firebirdsql.org/en/devel-mailing-lists/