[cmake-developers] Creating cdash subprojects: create_cdash_subprojects()

[David Cole]

Ambitious. I like it.

I would prefer seeing this implemented as a CMake-language function. And
adding anything necessary to CMake in order to support implementing it in
the CMake language.

(Because I think that adding such support would also enable a slew of other
unthought-of-as-yet functionality that will prove extremely useful...)

However, if that's not possible, or not your cup of tea, I would not fight
against including a native command to implement this functionality.

One problem I foresee with this right from the get-go is that it is very
complex and will be difficult to test well. And possibly difficult to figure
out what's gone wrong when something does go wrong.

You have time to prototype this in the CMake language and tell us what new
functionality we'd need to support it there? (I can tell we'll need commands
to iterate projects and targets... any others needed?)


- David


On Sun, Sep 26, 2010 at 9:27 AM, Alexander Neundorf <neundorf at kde.org>wrote:

> Hi,
>
> I'd like to set up subprojects for KDE, but I think this is right now not
> feasible because it needs too much manual work:
>
> when setting up subprojects for cdash, somebody has to write a Project.xml:
> <Project name=”Tutorial”>
>  <SubProject name=”Libs”>
>  </SubProject>
>  <SubProject name=”Exes”>
>  <Dependency name=”Libs”/>
>  </SubProject>
> </Project>
>
> This is too much manual work to be usable in KDE. Somebody (me initially)
> would have to go through each KDE module, figure out what subprojects there
> should be, how they depend on each other, and write that file. If something
> changes in the project, it has to be updated manually.
> I don't feel like trying to do that.
>
>
> Additionally , the following CMakelists.txt are required:
> • Name targets same as subprojects, base target names on
>  subproject names, or provide a look up mechanism to map
>  from subproject name to target name
> • Possibly add custom targets to aggregate existing targets
>  into subprojects, using add_dependencies to say which
>  existing targets the custom target depends on
>
> This is IMO basically impossible for KDE to implement and keep current.
>
>
> • Add LABELS target property to targets with a value of
>  subproject name
> • Add LABELS test property to tests with a value of
>  subproject name
>
> The items above should be really easy to do from within cmake.
>
> To make all that much easier, I propose to add a new command to cmake,
> which
> will do more or less all that:
>
> create_cdash_subprojects(PROJECTS p1 p2...)
>
> This command will
> * generate a Project.xml with one cdash subproject for each listed project
> (as
> in defined with the project() command)
> * Add a custom target for each of the listed projects, which depends on all
> the contained targets
> * Set the LABELS property automatically on all targets and tests
>
>
> How it should work:
>
> The command takes the listed projects and search them in the cmMakefiles.
> If it detects that one listed project is contained in another one which is
> also listed it reports an error.
> Otherwise, it collects all the targets contained in the project.
>
> After having done that, it knows which targets belong to which project, and
> it
> also knows which targets where not in any of the listed projects. These
> will
> be put into a separate cdash subprojects.
>
> Now that it has all the targets, it needs to figure out the dependencies
> between the targets/projects. I think this is the most complicated step.
> With
> this information, it can then write a Projects.xml.
>
> The next step is to add custom targets for each of the projects and let
> them
> depend on all contained targets. There shouldn't be major issues here ?
>
> Finally, it will iterate over all targets and tests and assign the
> respective
> LABELS properties. Here I also wouldn't expect trouble.
>
> With all that done, I think it should require more or less only one such
> create_cdash_subprojects() call per "parent project" (e.g. Paraview, or
> kdelibs, ...) and it should just work.
>
> What's left to do is to adapt the ctest script accordingly, but this
> doesn't
> seem to be too much work.
>
> Comments ?
>
> Alex
> Project.xml:
> _______________________________________________
> cmake-developers mailing list
> cmake-developers at cmake.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20100928/1cfbc5c3/attachment.html>