Goals for next Xfce releases

[Brian J. Tarricone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Jani Monoses wrote:
>>>               * autotools replacement.
>> Autotools are pretty much the de facto standard, for Linux at least.  To
>> depart from this we'd need a pretty compelling reason.
> 
> Agreed. We have lots of compelling reasons to switch (as I enumerated 
> them), the question is whether the compelling reasons to not switch are 
> more numerous.

Right, and I rebutted all your reasons.  Whether or not you agree with
my rebuttal is immaterial ^_~.

>>> Even with all the work going into 
>>> custom Xfce autotools scripts and at least one guru among the devs
>>
>> Really, automake isn't that hard.  After you wrap your head around the
>> idea that there are 'magic' Makefile.am variable names that do different
>> things, it's pretty easy to take an existing makefile and make it do
>> what you want for a new pacakge.  autoconf is a little harder, but,
>> again, there's a huge existing body of example configure.ac's that can
>> get you started.
> 
> that's the main problem, that you have to wrap your mind around 
> something which should stay out of the way.

I had to wrap my mind around pointers in C, but that doesn't mean we
should all go program in Java.

>>> these 
>>> still pose problems for those who build from svn (forgetting the 
>>> sequence of invocations or having to manually remove files or forcing 
>>> reruns etc),
>>
>> I don't see this as an issue.  Rule of thumb: if you do 'svn up', re-run
>> autogen.sh.  Unless your build system is missing stuff, this will
>> *always* work.  (Sure, there are times when you don't need to rerun
>> autogen.sh, but if you don't know how to identify these instances,
>> running it after every update will always work.)  At any rate, people
>> building from SVN are expected to know what they're doing.  If they
>> don't, then perhaps SVN isn't for them.   Hell, we even have several SVN
>> checkout/updater scripts that can do all this crap for you.
>>
> regardless, people are building from svn and many times you see mails on 
> thunar- and xfce-dev which are basically bug reports for the build 
> process or how it is understood by users and not the sw itself.
> Auke said it's better to educate them, well be my guests ;)

I wouldn't consider it "many", really.  Certainly not the most frequent
posts.  I'm very sensitive to repeated questions that have been answered
many times because it really annoys the hell out of me; build system
stuff doesn't come up all that much.

>>> for packagers (great PITA to carry a 1Mb diff of 
>>> autogenerated files to a package just because we changed one line and 
>>> had to run autoreconf).
>>
>> Then patch the Makefile itself, and not the Makefile.am.  If the changes
>
> That's uglier in most cases - I have done it once I think where the 
> makefil needed a one-line change, but generally a change in .am/.in 
> results in many dispersed changes in the autogenerated files.

Right, and what I'm saying is: don't change the Makefile.{am,in} files.
 Just hand-edit the Makefile itself.  If it really requires only a
one-line change, that's what you get: a one-line patch (well, ok, more
than one line for context, but you know what I mean).

>>> The tools work and do their job but maybe 
>>> there's something that can do the same without as much hassle.
>>
>> Maybe there is; feel free to research them and suggest something.
> 
> The research so far consisted of seeing that there are alternatives and 
> are used by larger projects than Xfce. You're ten-minute review of CMake 
>   is better research already as far as the details are concerned, and if 
> there are any showstoppers I'm all for sticking to autotools. I just do 
> not want to ignore other alternatives because of lack of information or 
> inertia.

I think inertia is a major driving factor here, and it should be.
Making a change to the build system shouldn't be undertaken lightly.  I
think cmake is interesting, but I don't really see benefits over
autotools.  Sure, it's "cleaner" (whatever that means), but it's just
another syntax to learn.  And not only that, it's a useless syntax to
learn: at least the autotools are based on languages that can be used
elsewhere (m4, bash, make rules, etc.).  For cmake they apparently
decided to reinvent the scripting wheel.  Why?

My cursory examination reveal several quirks of cmake, and I'd bet there
are many more.  Why trade autotools' quirks for cmake's quirks?

>>> It is not reasonable to expect people to read 10s of pages of docs 
>>> written for an era where there were dozens of different Unix flavors to 
>>> cater for.
>>
>> "People" meaning who?  No regular user needs to know or care about the
>> autotools, and, there *are* still dozens of UNIX flavers to cater to.
>> We don't just run on Linux.  We run on the *BSDs, Solaris, AIX, IRIX,
>> HP-UX, etc., and even Windows and MacOS X to some extent.  Fortunately
>> most of the UNIXes are starting to converge somewhat at least in libc
>> functionality and header locations/naming, but there are still enough
>> differences to make a framework like the autotools useful.
> 
>  From what I read KDE4 runs on Mac and Win and cmake made that a lot 
> easier for them.

Xfce runs on Mac and Win also.  (Though most of the desktop components
aren't too useful on either OS, IMHO.)  Yes, there were build-system
issues that had to be fixed to make this work.  Again, looking at cmake,
there are some specific Windows-isms, so I don't see this as a "Just
Works" solution.  The nifty thing about cmake is that it can generate MS
Visual Studio projects, or Apple Xcode projects.  While cool, I don't
think "generate project files for proprietary build systems on
super-minority platform" is compelling at all.

> I know that I filed at least 3 bugs I remember which are build-system 
> related and one was nasty too. I am sure there are plently reports in 
> bugzilla just like on the lists which are noise because they do not 
> concern what is built but how it is done.

And who says we won't get reports about different build problems with
another build toolchain?

>> Regardless, I don't think you appreciate the amount of work that
>> switching build systems would require.  We run on many many different
>> platforms, and the testing alone -- ignoring the actual migration effort
>> - -- would be much more work than most of us have time to do.
> 
> I repeat I did not say we should switch,

Sure you did.  If you didn't think we should switch, you wouldn't've
brought it up.

> let alone tell someone to do 
> the transition. It was one of the things I'd like to see in future Xfce

And now you're directly saying we should switch.  I'm getting confused.

> And it's not urgent and it's doable per module so it does not really 
> need a big decision. Some gnome module maintainers were eyeing cmake so 
> if they go that way there would be even less work for xfce as some 
> custom scripts would be ready.

Probably... maybe we can revisit this someday, but right now it just
doesn't seem necessary.

	-brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFv5ZS6XyW6VEeAnsRA0WTAJ4u3eo+Yc5L02LBNRruChQEGQxzNgCgkJPw
GPhw/LUcmm8+NWbDfNwAUms=
=NBpY
-----END PGP SIGNATURE-----