[scribus] 1.3.3.12 no odt support???

[Craig Ringer]

John Culleton wrote:

> The instructions for cmake describe a more complex and for me at least 
> confusing process than the traditional process. I recognize that the 
> developers see virtues in cmake. But perhaps after development is 
> completed the install process could be boiled down to the usual  
> method for us busy folks that keep many Open Source products on our 
> systems.

Unfortunately it can't be.

The two big virtues of Autotools are:

- They're familiar to users
- The final build scripts for released versions are just shell scripts.
They run without needing extra programs to be installed and work on most
systems with a shell, make, and some other core unix utilities.

That's about it. Alternative build systems all provide many other
advantages, like:

- Portability to Windows and to native Mac OS X IDEs
- much saner behaviour
- fewer weird corner cases and strange quirks
- more comprehensible to mortals
- Documented

... but generally require the installation of a build tool on the
system. This is increasingly viewed as a worthwhile trade-off.

Remember, you can save yourself a bunch of hassle by using packages anyway.

> If every product develops its own unique installation 
> software then life becomes unnecessarily complex.

Which is why, instead, they adopt build systems like CMake.

Autotools forces developers to build their own unique installation
software. As a user, you do not see this, but the developers sure do,
and waste many days or weeks on it. You as a user do see the bugs that
result from it.

Autotools is especially bad for Qt based software and other software
that needs additional build steps.

Time wasted on the build system is time not spent on more productive
coding like fixing bugs and writing enhancements to the software, so a
build system that's better for the developers actually benefits you
rather significantly.

Also, remember that the team aren't paid for this. They're doing it out
of personal interest in their own time. I hope you wouldn't generally
ask someone who's doing something for you for free to make it much
harder for themselves in order to slightly benefit your convenience -
and, when you think about it, that's what you're doing. That doesn't
mean that comments on the build system aren't valuable, of course, it
just means that "easier for the developers" is indeed a very good reason
for a build system change.

> I have seen other
> products (Inkscape as I recall) follow other paths looking for the 
> ideal installation system. But for the end user the ideal method is 
> something that works and is reasonably simple and universal. 

Increasingly, that's CMake.

It's far from perfect (in fact, in some ways it's downright horrible)
but it works well and it's infinitely saner than autotools. You'll find
that more and more projects (including KDE 4) are using it.

> Other Open Source products (e.g Gimp) compile and install nicely with 
> ./configure
> make
> make install
> and have for many years.  And Scribus used to.

I know. I was one of the people who wasted weeks fiddling with the
autotools scripts to track down and fix weird bugs and quirks so that it
would work that way. I suggest that you try it, and then tell me why
Scribus should use autotools. I promise you'll change your mind once you
try to work with it.

Autotools is actually pretty horrible for some end users too. If you're
building from cvs/svn you'll find that you have to

If there are features in the old autotools build system that you think
are missing in Scribus's new cmake build infrastructure, please explain
what you think is missing and how it should be improved. I'm sure the
feedback would be appreciated.

--
Craig Ringer