As discussed before, if we get a unified patch I will commit it ('long
as it doesn't break the scons build)...On 13/01/2009, Albert Santoni <[email protected]> wrote: > 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 > -- __ --- == __/ t.O ==-- http://stacktrace.org/ ------------------------------------------------------------------------------ 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
