On Fri, Dec 5, 2008 at 1:41 AM, Albert Santoni <[EMAIL PROTECTED]> wrote: > 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. Don't worry, I'm more or less in the same situation here ;)
>> * 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? It doesn't really, It merely special-cases Qt, where it uses the first qmake binary in the path ;) >> * 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? :) I don't have the presumption of knowing what's best for others, but in my case learning both was a good thing both for me and my employers as it makes our lives a lot easier. Sure it took some more work, but it was worth it. >> 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? -------8<----- > 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. CPack is a tool integrated with CMake that makes it easy to create installers for various platforms. I haven't used it yet, but it looks promising, using cpack should make building a windows installer a one-click affair (there's a new target called package, embedded). Plus, creating bundles for Mac OS should be relatively easy and the same should hold for rpm's http://www.cmake.org/Wiki/CMake:CPackPackageGenerators The best part: even if CPack doesn't cut it, cmake supports running custom commands as targets, so we can hack our solutions anyway we want. > 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. :) Don't worry about that, I've gone through the LFS stage and I can assure you that after working on AIX with grumpy admins, reeeeally crazy binary compatibility hacks and custom everything solutions, any linux distro is a relative joy ;) > 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. > :) Ok then, I'll see if I can work some more on this this weekend When learning cmake, I found this presentetion to be the most helpful and informative of the bunch. It doesn't cover everything of course, but it gives a pretty good intro. http://www.elpauer.org/stuff/learning_cmake.pdf -- Claudio Bantaloukas http://www.rdfm.org/ammuzzu/ ------------------------------------------------------------------------------ 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
