From: Jeff J. <jef...@gm...> - 2011-09-26 15:27:36
|
I am fairly new to GTK+ programming, but not new to programming so I thought I could offer a little fresh perspective. I have been working with the GTK+ toolkit for over a year now (CodeSlayer text editor) and coming from other toolkits/languages I did find it kind of painful to learn how to use the autotools. I mean when all you want to do is compile your code it is not very productive to have to take a long time to learn how to do that. I thought I really lucked out by having a Autotools (by John Calcote<http://www.amazon.com/John-Calcote/e/B002T8T75K/ref=sr_ntt_srch_lnk_1?qid=1317050027&sr=8-1>) book available and still reference that all the time. Now if CMake is really that much easier it could help lower the bar for more people to program in GTK+ / LXDE, which ultimately could help to get more work done. I keep my configure.ac file pretty vanilla but when I look at other projects to see how they did something tougher it can take a long time to figure out what is going on because there is nothing intuitive about it. But I have not used CMake so I cannot speak to whether it is really easier...and we all managed to learn the Autotools. -Jeff On Mon, Sep 26, 2011 at 9:38 AM, PCMan <pcm...@gm...> wrote: > On Mon, Sep 26, 2011 at 9:11 PM, Christoph Wickert < > chr...@go...> wrote: > >> Am Montag, den 26.09.2011, 12:40 +0800 schrieb PCMan: >> > Hi, >> > Since many people agreed that autotools is aged, horribly slow, >> > complicated, poorly documented, and hard to use correctly, I'm >> > currently doing some experiments with CMake, yet another build system. >> >> Hi, >> >> I don't recall people complaining about autotools and IHMO LXDE has >> other problems, e.g. the release of PCManFM 1.0, a stable version of >> LXPolkit or LXApperance-obconf and so on. Until this is done, we should >> not switch the build system. >> >> 1. Package doesn't build is a frequent problem we met, but autotols based > stuff is hard to fix and hard to get right. Extending it even requires mixed > m4 macro + shell scripts. I even spent more time on automake than real > programming, just to get my source code built. > > 2. Having a correct build process requires correct interplay between > autoconf, automake, libtools, and others, which exert different behavior in > different versions. > > 3. The build process by autotools is painfully slow. It's even slower if > libtool is used. This slow down the development. Everytime I modified the > source code, it takes much time to rebuild the new binary for testing. > CMakes runs much faster and has nice and clear compiler output. > > 4. The out of source build support is really useful. All generated files > are outside of the source tree. So virtually everything in the source > directory are required and should be in version control system. This greatly > decreases the maintaince load of developers and we will not have missing > files in the repo or we won't accidentally add some generated files to VCS, > which happens quite often in the past. > > 5. For people who type ./configure && make, this won't make visible > changes. However, this makes developers more productive. The later we do the > migration, the more things need to be rewritten and the migration may be > more difficult and time-consuming. So I don't think this should be given a > low priority, even when it looks less important. > > > From package maintainers' perspective, will using CMake make packaging >> > process more difficult? >> >> Not necessarily more difficult, but different. >> >> Regards, >> Christoph >> >> >> >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2dcopy1 >> _______________________________________________ >> Lxde-list mailing list >> Lxd...@li... >> https://lists.sourceforge.net/lists/listinfo/lxde-list >> > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > > |