On Tue, Jan 13, 2009 at 6:56 PM, Albert Santoni <[email protected]> wrote: > Hi Claudio, >> * 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. A language is a tool. From my point of view using python for cmake's purposes is like using a do-it-all-swiss-knife in order to perform heart surgery. I'm sure it can be done, but I'm also sure that that scissor would best be out of the way. Python is a great general-purpose language, just too powerful for what a build system needs.
Sometimes less is more. especially when it's more clarity. (But that's subjective). > 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. I'm perfectly ok with that, in fact, I encourage the use of scons as the default and supported build system. (I work in a company where cobol is used in 60% of our products, so I think I can spell the "Let's try new things but what works must still work" argument pretty well ;) ) >> * 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? Yes, at configure time, you have the choice of build tools to use, the list is here: http://cmake.org/cmake/help/cmake2.6docs.html#section_Generators Cmake performs checks for libraries that you may need, dependencies between code units (c++ files in our case) and generates the files that are needed by the chosen build tool collection. In the visual studio case a solution is created with all necessary files. It's also possible to just run nmake in the build directory from the command line. cmake is called at the beginning of every project build (IIRC it's a project called ZEROBUILD or something like that) to check that the CMakeFiles weren't altered. If they were, the configuration and local build tool file generation phase is re-run. This takes very little time as most values are cached, so if you forget to put a file in the list of files to build, it's a split-second matter. other than that, everything is driven by the local build system, be it make, nmake, xcode builder, borland builder, whatever... >> * 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. Well, I was luckier, someone else had made a FindQt.cmake script ready to use for me. I think that my laziness is showing up by now... ;) >> * 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? Probably not, scons works. Cmake works maybe 1% better, so I'm not asking for a switch, just to be able to build with cmake too when you check out from svn > 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. CPack works very well for Windows and MacOS. It doesn't work very well for linux packaging. It's not obligatory to use. The cool thing about it is that you do the equivalent of make package and that's it. You get the installer executable. > 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? It's a horrible bug caused by needing to pass multiple escaping methods... > 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. Well, I'm trying to achieve feature parity between the cmake and scons scripts so the easy way is to just add a custom target that does just that. :) However cpack looks promising, so I think I'll make a leap of faith and see where it takes me... > 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). I won't even try to make debian or ubuntu packages as this is the job for ubuntu and debian developers. Many debian developers think that upstream providing a debian directory is a PITA as it makes the debianisation process more complicated. I can't find the documentation for this though :( > 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.. No use for CDash now then :) > 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. That's ok with me. I just installed ubuntu on my new computer and will start working on cmaking ASAP :) Cheers! -- Claudio Bantaloukas http://www.rdfm.org/ammuzzu/ ------------------------------------------------------------------------------ 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
