Hi Claudio, Sorry for the delay. It's the end of the semester and work is piling up so I may be slow with my replies.
On 30-Nov-08, at 3:41 PM, Claudio Bantaloukas wrote: > On Sun, Nov 30, 2008 at 9:11 PM, Albert Santoni <[EMAIL PROTECTED]> > wrote: >> Hi Claudio, >> >> It's great to see your enthusiasm about Mixxx. Working on rewriting >> the >> build system for cmake sounds like a great way to learn about Mixxx's >> codebase and polish your cmake skills. > Well, you caught my main personal reason for writing a cmake based > build system right there. Just to learn more about mixxx. Code > acceptance is secondary to that. > >> Currently, there were no plans to migrate our build system away >> from SCons >> to something else. Our SCons build system was written last summer >> (2007), >> when we ported from Qt 3 to Qt 4. I don't think we've seen any major >> complaints about SCons coming from our developers, and if we were >> to move to >> another build system, we'd need some very good reasons. >> >> That being said, I'd be more than happy to discuss SCONS and cmake >> with you. >> What are the goals you intend to achieve by moving the build system >> to >> cmake? > To me a build system is infrastructure, it's scaffolding that enables > developers to work on their projects. To achieve better productivity, > infrastructure must be sufficient, robust, scalable but most > importantly non-intrusive. Enough but not more than necessary. > > The main goal of infrastructure is to allow a developer to work on the > code easily, using as few resources as possible, without getting in > the way. Taking this for granted, I think cmake handles this task > better than scons for a couple of reasons. > > * 1) There's no need to install python. Seriously, python is the best > thing since sliced bread and I've used it many times in the last x > years, but from a windows developer's perspective, it's just one more > dependency to add to the list... This is a fair point. > > * 2) There's no need to leave your IDE when compiling, even though I > suppose macros can be set up to run scons and automate the workflow With MSVC, you don't need to leave your IDE to use SCons either. Our Sconscript generates MSVC project files (although it calls SCons externally) too. > > * 3) I don't need to change the sconscript when the Qt directory > changes. This goes for all other libraries, as the find mechanism of > cmake is good enough for mixxx's needs This only happens on Windows and OS X because those platforms don't have any mechanism to automatically find headers. (pkg-config on Linux being sane, pkg-config on OS X being half-assed). How does cmake magically fix this problem on these platforms? > > * 4) I find the cmake syntax easier for the purposes of a build > system, thus more maintainable and debuggable, plus cmake keeps track > of all the platform-specific hacks that are currently embedded in the > SConscript Is learning another syntax easier for the rest of us though? I mean, Python so easy... and my brain hurts enough as it is, do we really want everyone to learn a new syntax? :) > > * 5) I like the purty culuz on the terminal telling me I'm 50% on > the way ;) > +1 for this one. :) > Plus, cmake brings cpack cdash and ctest on board. These technologies > might make it easier to package mixxx (at least under windows), and > enable running integrated tests on all platforms and keeping track of > whether there are problems with a patch on architectures other than > the ones where the developer is writing (I don't intend to keep a > windows laptop for long ;) ). Can you elaborate on how these might make Windows packaging easier? > > > I'm currently migrating the build environment at the company I work > for from a hodgepodge of Makefiles and scripts to cmake. It's a > no-brainer in our case as it means reducing build time from 1h to 5 > minutes (mainly due to the bugginess of said makefiles ;) ) > I've migrated the build system of another company in the past from a > custom shell script that called 40 slightly different makefiles (yuck) > to scons, and it worked like a charm, so I can say I'm not biased > against scons. > In the case of mixxx, scons is good enough. Cmake is just a bit > better, IMNSHO ;) > > None of these reasons are really good enough to justify the risk of > switching from scons to cmake right now. The cool thing is that the > two build systems can happily coexist without one stepping on each > other's toes. I'm willing to work on making cmake as good as, or > better than the current build system. If I succeed, reading the > CMakeLists files will be easy for all developers, and will become the > preferred way of working with mixxx sources. If I fail, a simple svn > rm CMakeLists.txt will resolve everything ;) > > Just let me give this a try and try it out ;) > My ears are open here. I'm trying to be unbiased since I was the one that wrote most of the SConscript (it's a mess, I know, I know). The packaging scripts we have embedded in our SConscript are super useful, I would hope cmake would allow us to do something like that too. I also want to point out that this will take more tweaking to get it to work for all Linux users than you expect. Don't underestimate the insane configurations that people have on their Linux boxes regarding paths and stuff. Many of these people also won't hesitate to blame your build system if it doesn't work for them. :) Anyways, like I said, my ears are open. I want to be clear that even by discussing this, there's no guarantee that we'll accept it. I'm interested in learning more about CMake, but I'm cautious because I know how much these build systems can be. I haven't had time to play with your CMakeLists.txt yet, but if I haven't commented on it again by like December 20th, poke me. :) Thanks, Albert ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
