What is the status of the Artichoke project?

[adamryczkowski]

I need to re-design our superproject in CMake that consists of several third-party fast-moving dependencies that we use as git submodules. I stumbled upon the Artichoke, and I think we might from it.

1. Unfortunately it seems as if the project lost impetus. Why is that? Are new functionalities added to the CMake somehow made the Artichoke obsolete?
2. Do you know of any open source project that uses the Artichoke, so I can download the source and study the code as an example?

[jcfr]

Hi Adam, Artichoke is a fine layer on top of External Project. It is now quite stable. It is is used daily in https://github.com/Slicer/slicer and associated extensions. Let me know if you have other questions. Hth Jc

…

On Mon, Dec 24, 2018, 12:28 PM Adam Ryczkowski ***@***.*** wrote: I need to re-design our superproject in CMake that consists of several third-party fast-moving dependencies that we use as git submodules. I stumbled upon the Artichoke, and I think we might from it. 1. Unfortunately it seems as if the project lost impetus. Why is that? Are new functionalities added to the CMake somehow made the Artichoke obsolete? 2. Do you know of any open source project that uses the Artichoke, so I can download the source and study the code as an example? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#35>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANXo8dSU136Yhvkk1K-6OJOtVsYbw20ks5u8Lp2gaJpZM4ZgXpP> .

[adamryczkowski]

I really love the way Slicer builds. Unfortunately not every use of the Artichoke is documented, and I still struggle to understand the big picture of what each of the function does (documentation only explains the meaning of the variables). That's why I am still not 100% sure if the Artichoke could help us.

What I want to achieve is
a) Clear way to send variables to external projects
b) One-step build of the whole project with the dependencies (like in Slicer).

An example project that uses the Artichoke would help a great deal. Do you know of any more simple project that uses Artichoke?

[adamryczkowski]

Another question: what is the exact reason for the files in Slicer/SuperBuild? Since they are in the repository, I assume they are manually written. But they include a lot of code that passes the arguments - the work I assumed Artichoke is doing.

Question number two: when and how exactly are they called? Are they simply included? On normal SuperBuild setup they would be included in the second pass of the CMakeLists.txt, but I tried to track the External_SciPy.cmake (the smallest file of all in the SuperBuild directory) and failed to find any reference to SciPy in any CMake code. Perhaps the names are somehow deduced, but if so - what is the mechanism? Is there any algorithm that automatically guesses the dependencies and calls the appropriate External_xxx.cmake files?

Do you know any other, simpler projects that use Artichoke?

[adamryczkowski]

Why exactly does Artichoke specifically handle its recursion? Is it only to calculate a nice indent for messages, or does it provide some important functionality?

The superbuild CMake idiom already supports infinite nesting in itself, and does not require the external projects to be aware of a superproject building it, at least this is how I know it.

[jcfr]

Hi Adam, I will provide a detailed answer in few days after I back from winter travel. Thanks and happy holiday Jc

…

On Fri, Dec 28, 2018, 12:40 PM Adam Ryczkowski ***@***.*** wrote: Why exactly does Artichoke specifically handle its recursion? Is it only to calculate a nice indent for messages, or does it provide some important functionality? The superbuild CMake idiom already supports infinite nesting in itself, and does not require the external projects to be aware of a superproject building it, at least this is how I know it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANXo9NT2e52xvxtyt-cwME33txymmgSks5u9gM6gaJpZM4ZgXpP> .

[adamryczkowski]

Are you back from the holidays...? ;)

I had to move on, so I conjured up my own CMake build system, that turned out to be even larger in scope than the Artichoke. I also called it a vegetable name, to honor your project. :) https://beetroot.readthedocs.io/en/latest/

I wonder if you would find time to answer my previous questions. External Project handling is still its Achilles' heel and I wonder if I can borrow some functionality from the Artichoke. Or perhaps (that would be the best) we could work together to merge those two projects.

[jcfr]

Hi Adam,

Thanks for the update. The beetroot project looks neat, and also great job on the documentation and logo

External Project handling is still its Achilles' heel and I wonder if I can borrow some functionality from the Artichoke.

One option could be to include the ExternalProjectDependency.cmake in beetroot

Or perhaps (that would be the best) we could work together to merge those two projects.

I have limited bandwidth to work on this but I would be happy to setup a video hangout to help clarify. Let me know what you think.

Here are answers to your questions

What I want to achieve is
a) Clear way to send variables to external projects

This is where Artichoke can help thanks to the mark_as_superbuild function.

b) One-step build of the whole project with the dependencies (like in Slicer).

This is already possible thanks to ExternalProject. The main idea is that the "outer project" builds the dependencies first and then it builds the "inner project.

Both outer and inner project share the same source tree. The difference is that the inner project is configured with a variable like ProjectName_SUPERBUILD set to OFF.

An example project that uses the Artichoke would help a great deal. Do you know of any more
simple project that uses Artichoke?

Makes sense. I created issue #36 to track this.

Another question: what is the exact reason for the files in Slicer/SuperBuild? Since they are in the repository, I assume they are manually written. But they include a lot of code that passes the arguments - the work I assumed Artichoke is doing.

The files are manually written.

Having variables set in the External_ file are specific to the project and do not need to declared or passed from somewhere else.

The mark_as_superbuild is relevant in scenario like these ones:

• pass build option used in the inner project (e.g Slicer_BUILD_DICOM_SUPPORT) and avoid duplicating code just to handle this
• pass variable like CMAKE_OSX_DEPLOYMENT_TARGET to all projects

Question number two: when and how exactly are they called? Are they simply included? On normal SuperBuild setup they would be included in the second pass of the CMakeLists.txt, but I tried to track the External_SciPy.cmake (the smallest file of all in the SuperBuild directory) and failed to find any reference to SciPy in any CMake code. Perhaps the names are somehow deduced, but if so - what is the mechanism? Is there any algorithm that automatically guesses the dependencies and calls the appropriate External_xxx.cmake files?

SciPy is actually a bad example, as it wasn't used anywhere and should be removed.

If you consider External_ParameterSerializer.cmake, it specified as a SlicerExecutionModel dependency here, then SlicerExecutionModel is specified as a dependency of Slicer here.

Do you know any other, simpler projects that use Artichoke?

This project is simpler: https://github.com/commontk/dcmjs

It is also used in the Slicer extension of type SuperBuild (e.g here) and also in some project that can be built either standalone or as Slicer modules (e.g here)

Why exactly does Artichoke specifically handle its recursion? Is it only to calculate a nice indent for messages, or does it provide some important functionality?

It has two roles:

• in the "first pass" recurse through all External_* project files so that it create the full list of dependencies based on the select build options
• display message with nice indents
• in the "second pass" it calls the regular ExternalProject_Add function passing ${${proj}_EP_ARGS} that was previously set by the call to ExternalProject_Include_Dependencies