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 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?
I'd hate to get most of the way done and find a killer problem at the last minute.
On Mon, Mar 24, 2008 at 8:29 PM, Jon A. Cruz <jon@...18...> 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?
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@...18...> 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@...1798...> 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@...18...> 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@...400...> 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
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@...400...> 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 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@...62...> 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@...400...> 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
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
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@...400...] 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
participants (7)
-
unknown＠example.com -
Aaron Spike -
Bryce Harrington -
Jon A. Cruz -
Joshua Blocher -
Kees Cook -
MenTaLguY