Inkscape

On Mar 24, 2008, at 2:30 PM, Joshua Blocher wrote:

> Guys,
>
> I'm current locked out of my sf.net account.
> As soon as i get back in i will commit what i have for cmake build
> system so far.
>
> Joshua L. Blocher

Hi Josh,

I'm one of those people who is a little cautious about changing build  
systems (imake, scons, etc.). Do you think you can look at the  
problems Kai-Uwe had recently with cmake?

http://www.behrmann.name/wind

I'd hate to get most of the way done and find a killer problem at the  
last minute.

Did you try to login to sf.net's website? You have to reset your password, then login to the website again, and then you'll be able to login on SVN.

If you've already did that, then I don't know.

-johan

> -----Original Message-----
> From: Joshua Blocher [mailto:verbalshadow@...] 
> Sent: maandag 24 maart 2008 22:30
> To: Engelen, J.B.C. (Johan); Aaron Spike; inkscape-devel
> Subject: Cmake build stuff
> 
> Guys,
> 
> I'm current locked out of my sf.net account.
> As soon as i get back in i will commit what i have for cmake 
> build system so far.
> 
> Joshua L. Blocher
>

On Mon, Mar 24, 2008 at 8:29 PM, Jon A. Cruz <jon@...> wrote:
>
>
>  On Mar 24, 2008, at 2:30 PM, Joshua Blocher wrote:
>
>  > Guys,
>  >
>  > I'm current locked out of my sf.net account.
>  > As soon as i get back in i will commit what i have for cmake build
>  > system so far.
>  >
>  > Joshua L. Blocher
>
>  Hi Josh,
>
>  I'm one of those people who is a little cautious about changing build
>  systems (imake, scons, etc.). Do you think you can look at the
>  problems Kai-Uwe had recently with cmake?
>
>  http://www.behrmann.name/wind
>
>  I'd hate to get most of the way done and find a killer problem at the
>  last minute.
>

Below are my responses to the points he brought up.
I also would hate to get caught at the last second.

I've looked at some of the generated makefiles and there biggest
dependencies( other than what you really need to build) is guess what
cmake. The ability to build makefiles without depending on itself
would be nice, but it is also kind of pointless since you have to have
cmake to build the makefiles to start with.  Unless you intend to not
distribute the Cmake build system files with whatever project you are
working on. That would cripple building on whatever other systems that
need projectfiles/makefiles built and most likely completely break
building out of source.
Cmake can be an automated configure script you can even rig it to
./configure script on *nix platforms. I'm not sure losing its Unix
feeling is a good or a bad thing.
As with anything how fast you can fix something in the system depends
on how well you know it.

Yes, you do have to learn new syntax if you are build the system from
scratch but for most developers its as simple as adding a file to a
list.
I would argue that this same with almost any build system not all
tools and dependencies are in one place.
Hmm, I will have to look into displaying default options or variables
this  more but I pretty sure its possible. I feel that it should
configure itself to use all the available optional stuff automatically
I easily trace wrong parameters to its source by going to the
Cmakelists.txt at the effected files are in.  Learning syntax is
something you will have to do eventual  but its far easier than auto*
IMO

Yes you can grab any random ENV like this SET(pc_path "$ENV{PKG_CONFIG_PATH}") .
As for the config.sit I don't know.
There is a cmake file that adds support for uninstalling.


Joshua L. Blocher
verbalshadow

I'm thinking that given how many things we're already looking to change,
On Wed, Mar 26, 2008 at 12:22:31PM -0600, Joshua Blocher wrote:
> On Mon, Mar 24, 2008 at 8:29 PM, Jon A. Cruz <jon@...> wrote:
> >  > As soon as i get back in i will commit what i have for cmake build
> >  > system so far.
> >
> >  I'm one of those people who is a little cautious about changing build
> >  systems (imake, scons, etc.).
> >
> >  I'd hate to get most of the way done and find a killer problem at the
> >  last minute.
> 
> Below are my responses to the points he brought up.
> I also would hate to get caught at the last second.

Josh, could you post this work up into a branch, for people to review?
I'm also concerned about switching us over all of a sudden, without more
people having a chance to review it and make sure it definitely is the
way we want to go.  With the refactoring projects being discussed,
changing the build system as well could either be very beneficial in
making that work easier, or could put a wrench in the works and generate
a lot of frustration...  so the more review ahead of time, the more
likely we'll be able to ensure things go smoothly.

For what it's worth, I don't have a strong feeling for or against cmake.
It's great to see people passionate about it in Inkscape, and I see
several big projects have converted over to it with good results.  I've
played with some simple cmake projects myself and was impressed by how
easily they could be put together, and how clear the config files and
syntax are.  It seems like a nice system, but autoconf/automake is a
known quantity and a lot of us at least have enough experience with it
to be able to get most stuff done.  Also, it sounds like most of the
benefits of cmake could be achieved in automake as well, if we just
educated ourselves on it better, and cleaned up the cruft that's
accumulated in our config scripts.  Fwiw, I suspect if we chucked our
automake stuff and replaced it with fresh, modern automake, we may be
able to achieve most of the benefits of cmake, *plus* we'd be able to
carry over specialized logic, tests, etc. from our old scripts where
those bits are still worth keeping.

So, I could go either way, but I'd like to make sure we have at least a
rough consensus on it among our most active svn users before we commit
to changing, and I'd like to have the chance to review and kick the
tires myself.

Bryce

I'm not sure if a branch is really even need as is right now since
cmake build files are not makefiles.
They shouldn't affect anyone not trying cmake out and since it not
complete yet there is little chance of that.
I worry about losing sync with trunk in a branch.

If the group feels that it better done in a branch i will put it there.

Joshua L. Blocher


On Wed, Mar 26, 2008 at 1:23 PM, Bryce Harrington <bryce@...> wrote:
> I'm thinking that given how many things we're already looking to change,
>
> On Wed, Mar 26, 2008 at 12:22:31PM -0600, Joshua Blocher wrote:
>  > On Mon, Mar 24, 2008 at 8:29 PM, Jon A. Cruz <jon@...> wrote:
>
> > >  > As soon as i get back in i will commit what i have for cmake build
>  > >  > system so far.
>  > >
>
> > >  I'm one of those people who is a little cautious about changing build
>  > >  systems (imake, scons, etc.).
>  > >
>
> > >  I'd hate to get most of the way done and find a killer problem at the
>  > >  last minute.
>  >
>  > Below are my responses to the points he brought up.
>  > I also would hate to get caught at the last second.
>
>  Josh, could you post this work up into a branch, for people to review?
>  I'm also concerned about switching us over all of a sudden, without more
>  people having a chance to review it and make sure it definitely is the
>  way we want to go.  With the refactoring projects being discussed,
>  changing the build system as well could either be very beneficial in
>  making that work easier, or could put a wrench in the works and generate
>  a lot of frustration...  so the more review ahead of time, the more
>  likely we'll be able to ensure things go smoothly.
>
>  For what it's worth, I don't have a strong feeling for or against cmake.
>  It's great to see people passionate about it in Inkscape, and I see
>  several big projects have converted over to it with good results.  I've
>  played with some simple cmake projects myself and was impressed by how
>  easily they could be put together, and how clear the config files and
>  syntax are.  It seems like a nice system, but autoconf/automake is a
>  known quantity and a lot of us at least have enough experience with it
>  to be able to get most stuff done.  Also, it sounds like most of the
>  benefits of cmake could be achieved in automake as well, if we just
>  educated ourselves on it better, and cleaned up the cruft that's
>  accumulated in our config scripts.  Fwiw, I suspect if we chucked our
>  automake stuff and replaced it with fresh, modern automake, we may be
>  able to achieve most of the benefits of cmake, *plus* we'd be able to
>  carry over specialized logic, tests, etc. from our old scripts where
>  those bits are still worth keeping.
>
>  So, I could go either way, but I'd like to make sure we have at least a
>  rough consensus on it among our most active svn users before we commit
>  to changing, and I'd like to have the chance to review and kick the
>  tires myself.
>
>  Bryce
>

On Mar 26, 2008, at 12:51 PM, Joshua Blocher wrote:

> I'm not sure if a branch is really even need as is right now since
> cmake build files are not makefiles.
> They shouldn't affect anyone not trying cmake out and since it not
> complete yet there is little chance of that.
> I worry about losing sync with trunk in a branch.
>
> If the group feels that it better done in a branch i will put it  
> there.

Well... as long as you don't break the build, then a branch might not  
be warranted.

However, I do think a good page on the wiki summarizing things would  
be helpful. Maybe include a table or two with feature support and  
requirements, etc.

For example, platform support is a key factor. I use SCons as an  
example. A while back the big project that adopted cmake had adopted  
SCons prior to that. Partly due to that we'd considered using SCons  
at least for a bit. However, when I tried to get a small project that  
used SCons working on OS X it failed. Aside from the project's scons  
scripts I even tried hacking the SCons sources themselves, but the  
basic problem hit was just a total blocker on OS X.

Oh, and I'm also *very* strongly against recursive make. Recursive  
Make Considered Harmful.

I've seen many "make is broken" problems solved by just moving away  
from recursive makefiles.

but... the main point is that a wiki page to collect this info would  
be most helpful.

On Wed, 26 Mar 2008 13:51:06 -0600, "Joshua Blocher" <verbalshadow@...> wrote:
> I'm not sure if a branch is really even need as is right now since
> cmake build files are not makefiles.
> They shouldn't affect anyone not trying cmake out and since it not
> complete yet there is little chance of that.
> I worry about losing sync with trunk in a branch.
> 
> If the group feels that it better done in a branch i will put it there.

So long as it doesn't disturb the existing build system, I see no reason
to do it in a branch.

-mental

Bryce Harrington wrote:
> Josh, could you post this work up into a branch, for people to review?
> I'm also concerned about switching us over all of a sudden, without more
> people having a chance to review it and make sure it definitely is the
> way we want to go.  With the refactoring projects being discussed,
> changing the build system as well could either be very beneficial in
> making that work easier, or could put a wrench in the works and generate
> a lot of frustration...  so the more review ahead of time, the more
> likely we'll be able to ensure things go smoothly.

I'd much rather see this in trunk where it can be tested. I shouldn't 
interfere with auto* build files unless someone tries to switch back and 
forth in a checkout. We've had multiple build systems living together in 
trunk for some time now happily... minus the regular forgotten update to 
one or the other. And this underscores the need for a unified build system.

Aaron Spike

Kai-Uwe Behrmann wrote:
> And the problem I see with current cmake "Makefiles" is not so much about 
> setting up a simple or big project, rather than to debug it. 
> In cmake I have no idea where veriables come from. In Make I do, at least 
> mostly. Learning debuging new feels a bit like a burden as it will need 
> quite extra time. On the other side make is pretty common.

That's weird. I seem to have opposite experience. Perhaps we need a more 
concrete example. It has been a while now since I did any work with 
CMake, but I remember thinking that it was great because the generated 
makefiles had comments that point to the line of the source CMake file 
that generated them. In my most recent trip though trying to debug 
autotools makefiles I was missing this help.


Aaron Spike

Kai-Uwe Behrmann wrote:
> # CMAKE generated file: DO NOT EDIT!
> # Generated by "Unix Makefiles" Generator, CMake Version 2.4
> 
> # Default target executed when no arguments are given to make.
> default_target: all
> 
> ...
> 
> all: cmake_check_build_system
>         $(CMAKE_COMMAND) -E cmake_progress_start /data3/CD/programme/fltk/djv_74b11/CMakeFiles $(CMAKE_ALL_PROGRESS)
>         $(MAKE) -f CMakeFiles/Makefile2 all
>         $(CMAKE_COMMAND) -E cmake_progress_start /data3/CD/programme/fltk/djv_74b11/CMakeFiles 0
> 
> ...
> 
> Do you have an other version or output? The above is just an example.

Here's a Makefile I have lying around from June of 2007:

# Include the progress variables for this target.
include progress.make

# CMAKE generated file: DO NOT EDIT!
# Generated by "MinGW Makefiles" Generator, CMake Version 2.4

#=============================================================================
# Set environment variables for the build.

SHELL = cmd.exe

# The CMake executable.
CMAKE_COMMAND = c:\cmake\bin\cmake.exe

# The command to remove a file.
RM = c:\cmake\bin\cmake.exe -E remove -f

# The program to use to edit the cache.
CMAKE_EDIT_COMMAND = c:\cmake\bin\CMakeSetup.exe

# The top-level source directory on which CMake was run.
CMAKE_SOURCE_DIR = C:\src\lib2geom

# The top-level build directory on which CMake was run.
CMAKE_BINARY_DIR = C:\src\2geom_build

# Default target executed when no arguments are given to make.
default_target: all

...

# The main all target
all: cmake_check_build_system
	$(CMAKE_COMMAND) -E cmake_progress_start C:\src\2geom_build\CMakeFiles 
$(CMAKE_ALL_PROGRESS)
	$(MAKE) -f CMakeFiles/Makefile2 all
	$(CMAKE_COMMAND) -E cmake_progress_start C:\src\2geom_build\CMakeFiles 0

...

Aaron Spike

Hi,

On Wed, Mar 26, 2008 at 01:23:04PM -0700, MenTaLguY wrote:
> On Wed, 26 Mar 2008 13:51:06 -0600, "Joshua Blocher" <verbalshadow@...> wrote:
> > I'm not sure if a branch is really even need as is right now since
> > cmake build files are not makefiles.
> > They shouldn't affect anyone not trying cmake out and since it not
> > complete yet there is little chance of that.
> > I worry about losing sync with trunk in a branch.
> > 
> > If the group feels that it better done in a branch i will put it there.
> 
> So long as it doesn't disturb the existing build system, I see no reason
> to do it in a branch.

I'm a few days late to this, but I thought I would reiterate some
comments I've made in the past about reworking the build system.  I
personally have no strong opinion about how it is implemented as long as
it meets a few requirements:

1- build system software is available on major distributions
2- performs fully parallelized builds
3- uses pkg-config or similarly correct dependency detection
4- correctly builds shared objects

I can't think of any others at the moment.  :)

I think all 4 are total show-stoppers if unmet.  In my (biased) opinion,
our distro maintainers will be highly displeased with the project if we
don't follow them.

Besides, I like being able to compile inkscape on 4 CPUs in under
6 minutes.  ;)

-Kees

-- 
Kees Cook

Kees Cook wrote:
> 1- build system software is available on major distributions
> 2- performs fully parallelized builds
> 3- uses pkg-config or similarly correct dependency detection
> 4- correctly builds shared objects

Would you be able to help us determine if CMake satisfies these 
requirements? Perhaps you could contact the Ubuntu packagers for other 
CMake using projects, such as Scribus.

Aaron

Kees,

On Tue, Apr 1, 2008 at 6:43 PM, Kees Cook <kees@...> wrote:
> Hi,
>
>
>
>  On Wed, Mar 26, 2008 at 01:23:04PM -0700, MenTaLguY wrote:
>  > On Wed, 26 Mar 2008 13:51:06 -0600, "Joshua Blocher" <verbalshadow@...> wrote:
>  > > I'm not sure if a branch is really even need as is right now since
>  > > cmake build files are not makefiles.
>  > > They shouldn't affect anyone not trying cmake out and since it not
>  > > complete yet there is little chance of that.
>  > > I worry about losing sync with trunk in a branch.
>  > >
>  > > If the group feels that it better done in a branch i will put it there.
>  >
>  > So long as it doesn't disturb the existing build system, I see no reason
>  > to do it in a branch.
>
>  I'm a few days late to this, but I thought I would reiterate some
>  comments I've made in the past about reworking the build system.  I
>  personally have no strong opinion about how it is implemented as long as
>  it meets a few requirements:
>
>  1- build system software is available on major distributions

Any distribution that Builds KDE( 3.x or 4.x ) currently has this
build system available.

>  2- performs fully parallelized builds

I believe you mean adjust the jobs i.e. -j20 if not let me know what you mean.

>  3- uses pkg-config or similarly correct dependency detection

Yes we use pkg-config for most things. there are a few like Boost and
BoehmGC that don't package .pc files that we have a Specfic macro to
detect.

>  4- correctly builds shared objects

You going to have to explain this one to me and how to test for it.
If it helps we will still be using our current same compilers/linker/etc.


If you come up with questions please let me know.

Joshua L. Blocher
verbalshadow