Hi Claudio, I'll try to explain my thoughts on cmake so far, to the best of my abilities:
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... It also has nice syntax, which a lot of people know anyways. Why did the cmake developers feel the need to write their own macro language? When I see projects making decisions that I have to question, it makes me skeptical of their direction. Picking a build system is a big deal, and if the developers of that build system are doing silly things, then it can have a big impact on your own project (in this case, Mixxx). I'm not saying SCONS is perfect or that the SCONS developers aren't doing silly things, but at least I know SCONS' limitations and problems right now. > > * 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 Better IDE integration would be great. However, SCONS made the same promises (eg. it'll generate MSVC projects for you), but it did not deliver very well. The project files it generates are set up to just call SCONS, which is probably a sane thing to do, but it can be annoying to get debugging working, etc. Does cmake do this any better? > > * 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 I think we just fixed this. :) In any event, I think this is/was a flaw in the way I wrote that part of the SConscript, and not a problem with SCONS itself. > > * 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 This is subjective, but for argument's sake, let's say cmake does have some mystically awesome syntax that's better than Python syntax. Is the time investment required to train the rest of us with cmake worth the switch? > > * 5) I like the purty culuz on the terminal telling me I'm 50% on > the way ;) > > 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 ;) ). Re: CPack - This looks completely useless. You can't "generate" packages magically based on some generic build file, packaging just doesn't work like that. To build a Debian package, you need to run the standard Debian packaging tools with some pre-setup "debian" directory. To build a Win32 installer, you need to run NSIS. CPack seems like it moves some of these options straight into cmake, but it loses flexibility because of it. Look at the example here: http://www.cmake.org/Wiki/CMake:Packaging_With_CPack Specifically, this awesome bit: SET(CPACK_NSIS_DISPLAY_NAME "${CPACK_PACKAGE_INSTALL_DIRECTORY} My Famous Project") SET(CPACK_NSIS_HELP_LINK "http:\\\\\\\\www.my-project-home-page.org") SET(CPACK_NSIS_URL_INFO_ABOUT "http:\\\\\\\\www.my-personal-home-page.com ") Why would you wrap NSIS variables like this? Why not just execute "nsis MyProgram.nsi"? If you write wrapper code like this, it breaks when the NSIS guys make changes. Again, this doesn't build my confidence in the CMake developers. We already have a build target that essentially just runs "nsis Mixxx.nsi" on Windows, and this does the job just fine, and is ultimately more flexible. Don't even get me started on Debian packaging as well. At the end of the day, the automated packages that you will produce won't be good enough to get into a repository, so they're not even that useful (as is the case currently). Re: CDash - Unfortunately, we don't have a build farm, so we can't use this. Our build process consists of me running some script or some scons target in my Windows VM, on my desktop PC, or on my Macbook.. > > 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 ;) > All of my arguments aside, I know both you and Helio are very keen on CMake and are willing to put in the effort to make it work. I'm willing to put the CMake file into trunk, but until we decide either A) we want to move to CMake entirely or B) we don't want to use CMake ever again, I'm going to say that our Mixxx developers will only be responsible for updating the SConscript. I don't want any of our active developers wasting time maintaining a second build script. If you want to do it, please go ahead. The other thing I want is a big fat warning printed when you run "cmake", saying that building Mixxx with CMake is unsupported, and that if it doesn't work, build with SCONS. Our users will be confused as hell when they see both a SConscript and a CMakeLists file, so this will hopefully help clear up the ambiguity. Thanks, Albert ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
