[cmake-developers] cmake issues and KDE

[Alexander Neundorf]

Hi,

several comments.

I have no idea why somebody (Thomas ?) created a wiki page for this, there is 
bugs.kde.org with a "product" buildsystem and there's the cmake bug tracker.

On Tuesday 08 August 2006 17:31, Brad King wrote:
> Bill Hoffman wrote:
> > At 10:02 AM 8/8/2006, Andy Cedilnik wrote:
> >> Hello,
> >>
> >> I read through those and here are my comments:
> >>
> >> ** CMake does not know the concept of subprojects
> >>
> >> *I think argument he is using is bad, but overall this one would be
> >> awesome for developers. Maybe having a way to compartmentalize sections
> >> of the code. For example in Slicer3, we have VTK, ITK, KWWidgets,
> >> Modules, etc. It would be really cool if we could designate parts as
> >> independent modules and not do dependency checking when running special
> >> targets. For example:
> >>
> >> make all/VTK
> >> make all/KWWidgets
> >>
> >> So, make all/Project or something similar would only build that project.
> >
> > I think the idea that we have been thinking about, would be :
> >
> > cd VTK
> > make  // this would only build VTK and lower depends
> > cd VTK/Common  // this would only build vtkCommon and lower
> >
> > but
> > make vtkCommon // this would do all the depends.
>
> Yes, it is just a matter of moving check_build_system to be a per-target
> thing and implementing a few more details in the way the makefiles are
> organized.  I'd love to do this but it may take some time (== money).

Yes, this would be cool.

> >> ** make install does not start an install until compiling finishes
> >>
> >> *The make install thing is there. Just set the appropriate variable
> >> (CMAKE_SKIP_INSTALL_ALL_DEPENDENCY).
>
> I love this one.  Severl users thought it was horrible that cmake did
> NOT do this in the past.  Now that it does it that is horrible for other
> users :)

What you read in the wiki is the opinion of one developer. I talked with David 
about setting CMAKE_SKIP_INSTALL_ALL_DEPENDENCY to TRUE, and he said that 
this would really be a bad idea.

Shouldn't "make install/fast" just do that, build the current dir and install 
it ? 

> >> ** editing CMakeFiles.txt forces an entire rebuild*
> >>
> >> Not sure about this one. I do know that you can mess-up cmake file so
> >> that it will always change something.
> >
> > We are sort of stuck with this one, they want local generate back.
>
> We could try some kind of save/load state of CMakeLists.txt file
> processing in each directory but it could get messy.  Let's just forget
> this one for now.

I'll ask for details. If this happens now, then something has been broken in 
our files (like rewriting config.h everytime).

> >> ** make install should not install files that have not changed
> >>
> >> *I thought we did this, but looks like we do not. Should be really easy
> >> to add.
> >
> > We did, I think the entry is incorrect.  Alex, can you fix that?
>
> Yes.  It reports that it is installing it but the file is not actually
> copied if it has not changed.  Perhaps we should change the message in
> the case that the file is unchanged:
>
> -- Installing /usr/include/myproj/myproj_changed.h
> -- File /usr/include/myproj/myproj_unchanged.h is unchanged

When cmake installed everything, people complained.
Now it installs only the changed files, packaging people complain that it 
doesn't install everything.
And people complain that it installs everything while it doesn't.

> >> ** The interface to cmake is not user friendly enough
> >>
> >> *Brad and I talked about this one and it would not be hard to implement.
> >> Especially with some of the new command argument parsing feature. I may
> >> look at this one once I convert command line argument parsing of CMake.
> >
> > A better command line interface would be good, the -D stuff is awkward at
> > best.
>
> Yes.

Is the plan with the command line shortcuts still active ?
Andy, did I understand you correctly that you will work on this ?
Otherwise I might have a look at it (but not this week).

> >> Anyway, good comments. Don't like the unsercmake idea... Whatever it
> >> does, we should do on the CMake level.
> >
> > The post-processing is horrible, and we need to address the issues so the
> > post processing is stopped.
>
> I think Thomas's time would have been better spent patching CMake than
> writing this script, but we'll get subprojects working eventually.

Yes.
But stuff like that is sometimes easier to implement in Perrl/Python/Ruby. 

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net