Proposal: Rework the build system from scratch

[philippremy]

EDIT: WIP (currently just for building some of the dependencies): https://github.com/philippremy/AliceVision-NBS

Hi everyone!

For the last few months I took a deep dive into the build system internals of AliceVision to re-enable macOS support. I already had the feeling before working on this that most of the users find it quite difficult to use correctly. I think the main reason is that AliceVision itself has so many different configuration options, which in turn lead to near infinite dependency combinations the user has to deal with. A more subtle reason is that - because CMake itself can be very complicated to use effectively - most of the changes in the build system created opaque patches which silently mixed and matched design concepts.

The things I found difficult to work with are especially:

• Configuration options are split between the top-level CMakeLists.txt and src/CMakeLists.txt, some of them silently changing behavior if AliceVision is built with or without embedded dependencies.
• include() and policy() calls do not have a global place to be set.
• The dependency builder does not work on Windows, and vcpkg does not reliably work on Unix.
• There are many legacy leftovers (like the Eigen alignment settings, which should be obsolete because the whole project requires C++20).
• Usage of deprecated features and variables, which can lead to uninformative calls to message(), etc.
• VLSift as a modified fork (an even issue mentions a licensing problem?)

My MR for the macOS support felt like making things even worse, instead of unifiying behavior between the systems. The result (at least for me on macOS) is a fragile build system which can do wrong things silently, if specific prerequisites are not met (see the install manual for example).

I propose a rewrite of the complete build system (with breaking changes). There are certainly many parts that can just be transferred (like the Helper modules, OptimizeForArchitecture, the new design of the dependency orchestrator, etc.). But I think that writing a clean and new CMake build system will make life easier for many people who are not deep into AliceVision's in-and-outs. Building on that would be to create a better CI (including different compilers) and maybe even start providing pre-built bundles for users to download.

Because the CMake minimum version already reached 3.30, another point would be to make the build system ready for CMake 4.X as well.

I would be willing to start some experiments myself (as a downstream fork first, eventually as a seperate branch for testing if wanted) and see if the situation can be improved. I wouldn't promise anything, but I feel like I have reasonable insight into what the build system can and cannot do.

But if there is no interest for this at all (whatever the reasons might be, I would just accept that of course!), I probably wouldn't spend too much time on this or even discard the idea completely. I know this is a heavy proposal, but from my POV it could be worth it :).

Thoughts are much appreciated :D.

[servantftransperfect]

Hello @philippremy,

This is a great idea.

We never took time to do that for years. I would be very happy to have a cleaner build / bundle system.

Maybe you can clean your thoughts and draft a proposal if you need to discuss more technically about that idea ?

Feel free to organize yourself the way you prefer.

Thanks for your participation.

[philippremy]

Yay!

I have some ideas (nothing super thought out yet), but I think the hardest part will certainly be the dependency management. Once I have something drafted together, I'll let you know :D.

[fabiencastan]

Linked to #1811

[philippremy]

A follow-up question regarding ffmpeg:

How intense is the attachment to ffmpeg for us? AFIK we do not depend directly (luckily) and it might only be used by OpenCV and OpenImageIO.

Because my personal preference would be to remove it entirely - finding it reliably is already hard and building it cross-platform... I think that is impossible. Neither OpenCV nor OpenImageIO are brave enough to provide an embedded build and the vcpkg portfile is around 1100 LOC, requiring MSYS on Windows.

But I can't really tell how much it is actually used out in the wild. If it really is needed, I would strongly oppose that we offer to build it embedded. That would just be a maintenance nightmare. And all the licensing implications not even mentioned. The user would need to provide it externally.

[servantftransperfect]

I think it is only a dependency for opencv.

[philippremy]

I'll leave it out then (for now). I mean it can still get picked up regularly by OpenCV if the user has it installed through a package manager, which should be sufficient in my opinion.

[philippremy]

The usual small update:

I am currently digging through all our dependencies and their respective transitive dependencies. I am trying to ensure that we do not accidentially introduce and licensing issues along the way. I don't know if anyone is aware of that, but as far as I can tell all the pre-built binaries will currently be licensed under GPLv3. This is due to SuiteSparse containing GPLv3 code in its CHOLMOD modules, which Ceres requires transitively through SuiteSparse's SPQR component.

That is not a huge problem in itself, but AliceVision also includes the Coin-Or CoinUtils, Clp and Osi packages which are licensed under the Eclipse Public License 2.0. As per the FSF documentation, this license is incompatible with the GPL, except when the license explicitly states that the licensed contents can be used under a "secondary license", which must be explicitly stated as GPLv2-or-later. From what I can tell, all of the Coin-Or projects AliceVision uses do have this exception.

Did anyone ever check this explicitly and/or does AliceVision have some kind of license management?

EDIT: My point being that because there are so many dependencies, I guess we are a little bit in license hell :DD.

[servantftransperfect]

I do think everything was checked before for Coin.

For SPQR, we can safely remove it from our build.

[fabiencastan]

We should not package SPQR as we do not want GPL contamination.

[philippremy]

Agreed. But that means a distributed pre-built Ceres will not have SuiteSparse compatibility, because it hard-requires SPQR. Alternatively it can use EIGENSPARSE if I recall correctly. For macOS that is not a problem either, because Ceres can use Accelerate.framework from Apple. I think we could technically allow the user to do this and guard everything behind a CMake option like ALICEVISION_ALLOW_GPL or something. I also plan on creating CMakePresets so that we have a preset for distribution which disables everything incompatible with distributing binaries.

[philippremy]

(I just post in here for information, I don't want to spam you guys :D)

I am also looking into rewriting all Coin-Or projects build systems to adhere to the newest CMake best practices, etc. I think this is something which should be done anyway and I will consider upstreaming this into their repos as well, but I don't know if I they want this.

The reason I am doing this is that I noticed our forks behave somewhat differently to the upstream projects when it comes to configuring, they are missing the latest sources and the installation appears to be a little different (compared to package-manager provided Coin-Or projects).

I already ported Coin-Or CoinUtils to a new CMake implementation (see my fork (branch bits/cmake)). Osi and Clp as well as LEMON will follow in the coming days.

[servantftransperfect]

I would like to add the dependencies on sycl in the docker(s) and cmake build. Did you start working on that ?

[philippremy]

Hi! No, not yet, sorry about that. And that is something I'll probably tackle last, because it is the most complicated. AdaptiveCpp with the generic backend requires a full LLVM build, which is huge and takes an eternity to build. So I'd say that this is a prerequisite which the user must have available, just like the regular C/C++ compiler.
I did not find any docker images or GitHub Actions specifically for AdaptiveCpp, but I didn't do a deep dive there yet. Otherwise we might need to write our own reusable containers/artifacts for AdaptiveCpp (that should be pretty straightforward if we cache the binaries accordingly).

If you just want something "quick and dirty":
Maybe it is worth using the adaptivecpp formula from Homebrew in the meantime, which would at least work on Linux and Apple (https://formulae.brew.sh/formula/adaptivecpp). The AUR also has an unofficial adaptivecpp package, but given the recent security issues, I am not sure whether the AUR should be used at all (and afaik we do not use any containers based on Arch, do we?).

As a side note: I'll step away from my current work until the end of the month, because I have some upcoming oral law exams I have to prepare for :^). But beginning with July I'll be back and continue working on this :). The current progress of my build system work is available here: https://github.com/philippremy/AliceVision-NBS. Not much to see yet, but small steps are steps :D.