Goals for next Xfce releases

[Jani Monoses]

>>               * 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.

> 
>> 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.

> 
>> 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 ;)

>> 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.

> are large enough that that's not feasible, either a) you're not doing
> something right, or b) we're not doing something right, in which case it
> behooves you to submit a Makefile.am patch to us.
> 
>> 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.

> 
>> 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.
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.

> 
>> It is weird to have the boilerplate scripts and code of the 
>> build system be larger than the actual code it helps to build.
> 
> Yeah, you'll get no argument from me here.
> 
>> I think
>> Jannis at one point looked at Scons and cmake or at least there were 
>> files that suggest that in one of the plugins, I think verve.
> 
> Which he later ditched, I think because they sucked.
No idea why, I just saw those files appear and then disappear from the 
tarballs. He may want to share his findings :)

> 
> 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, let alone tell someone to do 
the transition. It was one of the things I'd like to see in future Xfce 
that's all and wanted to see initial reactions. At least your concerns 
are more reasonable than Benny's 'Err, no' ;) But he did a lot of work 
on xfce-dev-tools to get autotools to suck less so... If any work gets 
done or not and who does it it's another topic.

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.

Jani