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.

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

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

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

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

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

> The fact 
> that KDE which is a more complex codebase transitioned from autotools to 
> cmake without loosing portability is promising.

Last I looked (a very long time ago), they were using qmake.  I don't
recall them ever using autotools.

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.

If we're gonna adopt a different build system, let's see a patch to
actually do it for at least one or two of the modules with more complex
build rules, plus some really strong rationale why build system X is better.

>                              printing - distros already have their messy 
> and different ways of handling printers, I hope one of the the existing 
> 2-3 GTK/gnome based ones makes it to more than one distro.

Gtk has its own printing system as of 2.10 or 2.12 or something.  I'm
not sure if it handles printer discovery and configuration, though.

	-brian

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

iD8DBQFFvnZI6XyW6VEeAnsRA9/rAKCqRmldrSJpnabAuHb8TVdlHudpmwCfQVab
fuWb/e7cK2v4L3/w1Xi2bFc=
=b7n0
-----END PGP SIGNATURE-----