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 <[email protected]> wrote:
> On Mon, Sep 26, 2011 at 9:11 PM, Christoph Wickert <
> [email protected]> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/lxde-list
