Rosegarden

On Sunday 05 November 2006 5:24 pm, Pedro Lopez-Cabanillas wrote:
> I have committed to the Rosegarden repository (branches/reorganisation)
> some preliminary CMake build system support files. It is far from be
> finished. It doesn' t install anything, and most of the 3rd library checks
> are still pending, but it may be used instead of reorganise-makefile and
> see what it looks.

OK, I'll have to get back to you.  My distro has an old cmake, so I'm building 
the new one from source, and it's going to take more time than I have to play 
with both.

Thanks for getting this ball rolling though.  Nice to have you back from 
whatever rock you've been hiding under.  :D

-- 
D. Michael McIntyre 

Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/
See my new music stand unfolding at http://users.adelphia.net/~silvan/

On Sunday 05 Nov 2006 22:24, Pedro Lopez-Cabanillas wrote:
> You need at least CMake 2.4 for KDE support.

Hm, that's a bit of a worry.  I wonder whether you can easily get that across 
distributions at the moment?  What's the situation like for e.g. Fedora 
users?

I run several machines based on Debian stable myself, and that only has 2.0.5.  
For optional libraries I don't care so much, but I don't want people having 
to faff about building something else before they can even try to run the 
Rosegarden configure stage.  Come to that, I'm not so keen on having to build 
the thing myself before I can test it out.

I think we need to approach this with some care.  We seem to have become very 
keen to switch from scons just on the basis that KDE is doing so -- it's not 
quite clear to me what exactly is wrong with it for us.  I'm not fond of 
scons myself, but that's really down to my aversion to Python; I can't say I 
regularly notice actual problems with it.  What are they?  Are they problems 
in scons, or in our scripts?

I haven't tried the cmake build yet, but two things about it look good -- the 
simple configuration files, and the fact that it builds to Makefiles.  If the 
Makefiles turn out to be simpler than those from autoconf, then all the 
better.

I am seriously considering trying a competing build system based on autoconf.  
No automake or libtool, just a relatively simple configure stage with a 
single hand-built Makefile.in, probably working by building all files using 
wildcards, as reorganise-makefile does, instead of listing the sources.  We 
don't need to build any interim libraries, and GNU make is really good at 
handling shell callouts and wildcards.  Hey, we could even use makedepend.  
But you can pretty much guarantee I won't get around to it.

One reason I'm tempted is that I think the biggest problem with all our build 
systems to date has been an over-reliance on the inclusion of "magic scripts 
from KDE".  These invariably seem to be hideously complicated things that are 
designed to do all the work for building KDE component libraries, but that 
for us are overengineered and fragile.  The suggestion that we need to use a 
newer version of cmake than I have available, so that we can use functions 
with names like KDE3_ADD_DCOP_SKELS, is giving me that same feeling again.  
Building DCOP stuff is really not hard -- it's like half a dozen lines in 
reorganise-makefile.  It's more that the existence of all these complicated 
macros that do it gives us the feeling that it must be hard, so we never 
bother to learn what it actually involves.


Chris

I tried the binary download of CMake 2.4.3 from cmake.org, and it works fine.
So that's a good start.

I then ran

cmake .
make

and I got this:

/usr/bin/c++   -I/usr/include/alsa   -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -O2 -Wformat-security -fno-exceptions -fno-check-new -fno-common -fexceptions -iquote /home/studio/rosegarden/reorganisation/src -g -I/usr/include/kde -I/usr/share/qt3/include -I/usr/local/include -I/usr/include/freetype2 -I/home/studio/rosegarden/reorganisation/src/base -I/home/studio/rosegarden/reorganisation/src/sound   -D'VERSION="1.5.0-reorg"' -DQT_SHARED -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -D_REENTRANT -DQT_CLEAN_NAMESPACE -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DHAVE_ALSA -DHAVE_LIBJACK -DHAVE_DSSI -DHAVE_LADSPA -DHAVE_LIBLO -DHAVE_LIBLRDF -DHAVE_XFT -o src/sound/CMakeFiles/RosegardenSequencer.dir/AlsaDriver.o -c /home/studio/rosegarden/reorganisation/src/sound/AlsaDriver.cpp
c++: cannot specify -o with -c or -S and multiple compilations

It looks like the argument to "-iquote" is being treated as a source file.
I don't know what -iquote is supposed to do, and it doesn't look like my
compiler (gcc-3.3.5) does either.  Replacing -iquote with -I fixes it.  I
made that change in the top-level CMakeLists.txt, and building continues.

(Also the remaining -I options listing other bits of the Rosegarden tree
are redundant -- we only need one, the src directory itself.)

I like the percentage completion indicator.


Chris

On Monday 06 Nov 2006 10:44, Chris Cannam wrote:
> [...] building continues.

Well, it built.

I have to say I'm still only half keen.

Pros:

 * CMakeList syntax looks straightforward enough.

 * Extension through modules in cmake_admin looks comprehensible.

 * Good feedback during compiling, nice progress indicator.

 * There is a generally solid feel about the cmake program.

   You get the impression it's been pretty heavily tested.  It didn't
   seem to do anything I didn't expect.

 * Easy to obtain cmake.

   This is really only a mitigating factor for the problem that it has
   to be obtained at all.

 * Appears to do the right thing for cross-Makefile dependencies.

I had mentioned "produces makefiles" as a pro; I'm not mentioning it this 
time, because it turns out the makefiles are far too complicated to be used 
or tweaked independently of CMake.

Cons:

 * Requires a tool users won't necessarily have.

 * Generates a staggering amount of supporting cruft.

   I counted a total of 96 files generated by the configure and build
   process (not counting directories or the usual object files).

 * No way to remove the supporting cruft (no "make distclean").

   The docs suggest that this doesn't matter because you should be
   building to a separate build directory.  I would accept that if the
   default was to build to a separate build directory, but it isn't.

   What's particularly odd is that most of the generated and object
   files _do_ get written to special directories (the CMakeFiles
   directories) -- just not quite all of them.

 * Some of the output is so verbose and/or weird as to be offputting.
   The stuff you get when you type "make" and there's no work to be
   done, for example, is just excessive.

I would much rather have only a single makefile (or at most two, one in the 
top-level directory and one in src/).  16 generated files is still a lot, but 
it's much better than 96, and it would cut down on the verbiage as well as 
there would be, and should be, no need to change directories.  If the 
makefile was too large and unwieldy with all the file names in it, it could 
perhaps include lists of files from the individual directories.  Or I'd 
probably rather it wildcarded the list of source files itself.


Chris

On Monday, 6 November 2006 11:22, Chris Cannam wrote:
> On Sunday 05 Nov 2006 22:24, Pedro Lopez-Cabanillas wrote:
> > You need at least CMake 2.4 for KDE support.
>
> Hm, that's a bit of a worry.  I wonder whether you can easily get that
> across distributions at the moment?  What's the situation like for e.g.
> Fedora users?

I've done a quick survey using this search engine:
http://rpmfind.net/linux/rpm2html/search.php?query=cmake

There are official packages (in Extras) for Fedora Core 4, 5, 6 and the 
currently development Core 7. Also for OpenSuSE and Mandriva development 
repositories.

I would expect to be included in all the major distributions very soon, as it 
is already being used now to develop KDE4 by many people, including the 
employees of the bigger Linux companies.

> I think we need to approach this with some care.  We seem to have become
> very keen to switch from scons just on the basis that KDE is doing so --
> it's not quite clear to me what exactly is wrong with it for us.  I'm not
> fond of scons myself, but that's really down to my aversion to Python; I
> can't say I regularly notice actual problems with it.  What are they?  Are
> they problems in scons, or in our scripts?

The main problem with bksys/scons is that bksys is not maintained anymore. But 
if anybody likes it and wants to take the responsibility, I have nothing 
against. 

I've only added a few text files to the repository, without erasing anything 
at all. If we don't like CMake after all, we can get rid of it very easily.

Regards,
Pedro

On Monday, 6 November 2006 11:44, Chris Cannam wrote:
> It looks like the argument to "-iquote" is being treated as a source file.
> I don't know what -iquote is supposed to do, and it doesn't look like my
> compiler (gcc-3.3.5) does either.  Replacing -iquote with -I fixes it.  I
> made that change in the top-level CMakeLists.txt, and building continues.
>
> (Also the remaining -I options listing other bits of the Rosegarden tree
> are redundant -- we only need one, the src directory itself.)

I've made a comment already about the '-iquote' compiler parameter (I've was 
wrong about its purpose). I think I can remove it. Of course, all the include 
directories and flags need to be reviewed more carefully.

Regards,
Pedro

On Monday, 6 November 2006 15:18, Chris Cannam wrote:
> On Monday 06 Nov 2006 10:44, Chris Cannam wrote:
> > [...] building continues.
>
> Well, it built.
>
> I have to say I'm still only half keen.
>
> Pros:

[...] 6 positive points for CMake from Chris.

> Cons:
>
>  * Requires a tool users won't necessarily have.

I've already commented this point. It is already available for many distros, 
it can be easily obtained otherwise, and I expect to become very popular, 
because is the tool needed to build the forthcoming KDE4.

>  * Generates a staggering amount of supporting cruft.
>
>    I counted a total of 96 files generated by the configure and build
>    process (not counting directories or the usual object files).
>
>  * No way to remove the supporting cruft (no "make distclean").

I've included a bash script in scripts/clean_cmake_files to do so (and you 
were  discouraged to build inside the source tree, anyway :-). It is possible 
to add custom targets to the Makefiles, so I can add the "distclean" target 
if you insist to not use the out-of-sources approach.

>    The docs suggest that this doesn't matter because you should be
>    building to a separate build directory.  I would accept that if the
>    default was to build to a separate build directory, but it isn't.

This can be done, also. You can add a second argument to the 
ADD_SUBDIRECTORY() function, which would become the output directory. I would 
prefer to not make it a mandatory policy, though.

>  * Some of the output is so verbose and/or weird as to be offputting.
>    The stuff you get when you type "make" and there's no work to be
>    done, for example, is just excessive.

I have enabled the verbose output by default: SET(CMAKE_VERBOSE_MAKEFILE ON), 
because it is better to debug the build system, and anyway the compiler 
output and command lines are needed by Eclipse to build the error and warning 
lists, which I like a lot. This option can be disabled by default after the 
build system becomes more mature.

> I would much rather have only a single makefile (or at most two, one in the
> top-level directory and one in src/).  16 generated files is still a lot,
> but it's much better than 96, and it would cut down on the verbiage as well
> as there would be, and should be, no need to change directories.  If the
> makefile was too large and unwieldy with all the file names in it, it could
> perhaps include lists of files from the individual directories.  Or I'd
> probably rather it wildcarded the list of source files itself.

You will face two challenges: check 3rd party libs, allowing the user to 
specify some options, and fulfill some requirements as the ones requested by 
yourself: handle dependencies properly between sources dealt with in 
different Makefiles, and build things in the right order when invoked with -j3

Regards,
Pedro

On Monday 06 Nov 2006 19:07, Pedro Lopez-Cabanillas wrote:
> On Monday, 6 November 2006 15:18, Chris Cannam wrote:
> >  * Requires a tool users won't necessarily have.
>
> I've already commented this point. It is already available for many
> distros, it can be easily obtained otherwise, and I expect to become
> very popular, because is the tool needed to build the forthcoming
> KDE4.

Yes, I think it's not as significant as I first assumed when you said 
we'd have to have the 2.4.2 version or newer.  That's partly because I 
found the static binary distribution worked so easily.

> (and you were  discouraged to build inside the source tree, anyway
> :-).

I deliberately tried the default build first, because it's what I would 
do as a naive user and what I expect other naive users to do.  And 
actually, I don't really care where the object files go -- not that 
that's quite relevant, since it turns out that even in the default 
in-tree build scenario the object files go into separate directories.

> >  * Some of the output is so verbose and/or weird as to be
> > offputting. The stuff you get when you type "make" and there's no
> > work to be done, for example, is just excessive.
>
> I have enabled the verbose output by default:
> SET(CMAKE_VERBOSE_MAKEFILE ON), because it is better to debug the
> build system, and anyway the compiler output and command lines are
> needed by Eclipse to build the error and warning lists, which I like
> a lot. This option can be disabled by default after the build system
> becomes more mature.

OK, fine.

> > I would much rather have only a single makefile [...]
>
> You will face two challenges: check 3rd party libs, allowing the user
> to specify some options, and fulfill some requirements as the ones
> requested by yourself: handle dependencies properly between sources
> dealt with in different Makefiles, and build things in the right
> order when invoked with -j3

I'm not quite sure what you're replying to here.  Your reply reads like 
a (legitimate) response to my suggestion about doing a hand-crafted 
autoconf/Makefile combination.  In which case, I think checking 3rd 
party libraries is fairly easy; handling user options (especially for 
packagers, who I have to admit I don't care a great deal about in 
comparison to end-users and us) is trickier; making sure everything 
gets installed in the right place is potentially tricky too.

However, when I said I'd rather have a single makefile just above, I 
wasn't talking about hand crafting it -- I was intending to refer to a 
single CMakeLists.txt and a single set of cmake generated files instead 
of one per directory.  i.e. still using cmake, but without the 
plurality of makefiles.  If you have subdirectories with totally 
separate targets (different executables or libraries) or containing 
code from quite separate origins (such that they'd normally be expected 
to be built separately) then it's probably reasonable to have separate 
makefiles, but otherwise there's very seldom any advantage.  For us, I 
probably wouldn't even bother with separate makefiles for rosegarden 
and rosegardensequencer unless we really have to, since one is never 
installed without the other.

Of course, handling dependencies between makefiles and building in the 
right order with -j3 are not a problem when you only have one makefile.  
Not that they seem to be a problem with cmake anyway.


Chris

On Monday, 6 November 2006 20:27, Chris Cannam wrote:
> I was intending to refer to a single CMakeLists.txt and a single set of
> cmake generated files instead of one per directory.  i.e. still using cmake,
> but without the plurality of makefiles.    

Ah, OK. I will try this approach. Also, to have a single CMakeLists file using 
some auxiliary small files, for better maintainability.

Regards,
Pedro

On Monday 06 November 2006 11:22, Chris Cannam wrote:
>
> I think we need to approach this with some care. =C2=A0We seem to have =
become
> very keen to switch from scons just on the basis that KDE is doing so -=
-
> it's not quite clear to me what exactly is wrong with it for us.=20

Strictly speaking, nothing, short of using an abandonned system. We could=
 very=20
well refurbish our scripts to work on the reorg branch, but it's true tha=
t at=20
one point or another, we'll have to migrate to cmake, so Pedro did the ri=
ght=20
thing here.

--=20
Guillaume.
http://www.telegraph-road.org

On Monday 06 November 2006 9:18 am, Chris Cannam wrote:

> Well, it built.

Built here too.  I'm going to inject all my related comments in this one 
message

> I have to say I'm still only half keen.

I rather like it, I must say.  It looks and feels solid.  Cons for scons other 
than abandonment, the damn thing always felt like we just barely had it 
working with the right combination of duct tape and kite string.  There was 
some weirdness with the LIRC dependencies always getting checked on every 
build, and all manner of assorted other vague and niggling things that never 
inspired a lot of confidence.

>  * Good feedback during compiling, nice progress indicator.

I quite like that.

>  * Easy to obtain cmake.
>
>    This is really only a mitigating factor for the problem that it has
>    to be obtained at all.

I don't see this as a terribly large problem.  Most users wait for distro 
packages anyway.

As far as the in-tree or out-of-tree, I think most users will be just like 
me.  "CMake?  What the hell is this?  How do I build something with this?"  
So they will be more inclined to read the instructions we provide.

I have no opinions on the more technical details.  As long as the damn thing 
works, and I can figure out how to add a new file to it later, I really don't 
care what you three work out on what where and how many.

-- 
D. Michael McIntyre 

Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/
See my new music stand unfolding at http://users.adelphia.net/~silvan/

On Tuesday 07 Nov 2006 00:44, Guillaume Laurent wrote:
> but it's true that at one point or another, we'll have to migrate to
> cmake

No, we won't.  There is absolutely no good reason why we should always 
use the same build system as KDE.  In fact, so far we would probably 
have been better off never copying any of the KDE build system: it's 
caused us far more pain than it's been worth.

How about we finally, for the first time ever, pick a build system on 
the basis of how good it is rather than who else is using it?

That said -- I've just done a complete build of the trunk on a slow 
laptop, taking over an hour, only to discover afterwards that

  scons configure debug=off

configures for a debug build!

(Yes, I was too lazy to check the docs in the SConscript before running 
and remind myself what option did what.  No, I didn't remember to check 
the compile flags being printed out during the build.  There isn't any 
specific diagnostic information from scons about this, though.)

This kind of nonsense is after all a pretty good reason for moving away 
from scons, or at least from our set of scripts for it.  It's also why 
we really need a slightly more complete CMake implementation (that 
handles options like this, as well as installation) before we can 
really judge whether we want to go on and use it or not.


Chris

On Tuesday 07 November 2006 17:01, Chris Cannam wrote:
>
> No, we won't.  There is absolutely no good reason why we should always
> use the same build system as KDE.

Beyond the fact that they have solved the same problems that we would have to 
solve, there isn't.

> How about we finally, for the first time ever, pick a build system on
> the basis of how good it is rather than who else is using it?

How do you think KDE chooses its own ?

> This kind of nonsense is after all a pretty good reason for moving away
> from scons, or at least from our set of scripts for it.  It's also why
> we really need a slightly more complete CMake implementation (that
> handles options like this, as well as installation) before we can
> really judge whether we want to go on and use it or not.

Which is exactly what KDE has been working on (except it works for KDE4 at the 
moment).

-- 
Guillaume.
http://www.telegraph-road.org

On Tuesday 07 Nov 2006 16:13, Guillaume Laurent wrote:
> On Tuesday 07 November 2006 17:01, Chris Cannam wrote:
> > No, we won't.  There is absolutely no good reason why we should
> > always use the same build system as KDE.
>
> Beyond the fact that they have solved the same problems that we would
> have to solve, there isn't.
>
> > How about we finally, for the first time ever, pick a build system
> > on the basis of how good it is rather than who else is using it?
>
> How do you think KDE chooses its own ?

Ooh, I don't know -- do you think they test some and pick the one that 
appears to be best, instead of picking up whatever another project 
happens to use?  You'd hope so, wouldn't you?

Your comments there are both just appeals to authority -- if KDE does 
it, they must have a good reason for it, so we should do it too.  But 
the requirements for KDE are often quite different from the 
requirements we have, and what may have worked for KDE in the past 
hasn't worked well for us.

If there's one thing worse than having a build system that doesn't work 
terribly well, it's having a build system that doesn't work terribly 
well and that you can't practically fix because all the logic is tied 
up in someone else's overengineered project-specific scripts.  That's 
what's happened to us so far, just for the sake of some poxy dozen 
lines' worth of stuff that really does happen to be specific to KDE but 
that it'd be no problem to do ourselves if only we could be bothered to 
understand how.

Of _course_ if a system like CMake has nice built-in stuff to handle the 
KDE dependencies, then great, that's a big advantage.  But it's far 
from enough to sell a system on its own.

Let's just keep testing it and see.  It looks promising so far.


Chris

On Tuesday 07 November 2006 17:30, Chris Cannam wrote:
> On Tuesday 07 Nov 2006 16:13, Guillaume Laurent wrote:
> >
> > > How about we finally, for the first time ever, pick a build system
> > > on the basis of how good it is rather than who else is using it?
> >
> > How do you think KDE chooses its own ?
>
> Ooh, I don't know -- do you think they test some and pick the one that
> appears to be best, instead of picking up whatever another project
> happens to use?  You'd hope so, wouldn't you?

No, I'm subscribed to kde-devel and kde-core-devel, I've read and participated 
to the discussions which have led to the eventual choice of CMake as a build 
system. If scons/bksys was choosen at some point, it's in part because I had 
vouched for it and told that switching to it for RG went rather well. So I 
know how scons and then cmake ended up being chosen, and it was not 
because "somebody else is using it". That criteria was actually almost never 
considered, because given KDE's weight, as soon as they start using 
something, it becomes de facto mainstream.

> Your comments there are both just appeals to authority -- if KDE does
> it, they must have a good reason for it, so we should do it too.  But
> the requirements for KDE are often quite different from the
> requirements we have, and what may have worked for KDE in the past
> hasn't worked well for us.

Not different, our requirements are a superset of KDE's. But the transparent 
handling of uic, moc, and dcopidl are something I'm not too keen on 
re-inventing, for instance.

I don't understand why you're painting things so black all of a sudden. The 
autotools were a pain mostly because of strange unrepeatable behavior (like 
the -fno-exception option chronically creeping in), but that's about it. 
scons/bksys has been relatively pain-free. I expect cmake to behave 
similarly, and when we migrate to KDE4, I don't see any reason not to use 
KDE's build system again.

-- 
Guillaume.
http://www.telegraph-road.org

On Tuesday 07 Nov 2006 17:36, Guillaume Laurent wrote:
> On Tuesday 07 November 2006 17:30, Chris Cannam wrote:
> > On Tuesday 07 Nov 2006 16:13, Guillaume Laurent wrote:
> > > How do you think KDE chooses its own ?
> >
> > Ooh, I don't know -- do you think they test some and pick the one
> > that appears to be best, instead of picking up whatever another
> > project happens to use?  You'd hope so, wouldn't you?
>
> [...] I know how scons and then cmake ended
> up being chosen, and it was not because "somebody else is using it".

That's what I was saying, but perhaps my sarcasm was missed.  My point 
was that if the KDE project can choose a system on its merits for their 
use, why can't we?

The reason I'm being so grumpy about this is mostly due to exasperation 
with comments like "at one point or another, we'll have to migrate to 
cmake".  We don't _have_ to do anything of the sort, and we never will 
_have_ to.  How are we supposed to make a rational decision if we start 
out by assuming the result?

> Not different, our requirements are a superset of KDE's.

Not at all.  We don't build any shared libraries, we target one 
platform, we have no system-level code (requiring root privileges for 
example) and so on.  Our requirements are far simpler in the respects 
in which KDE's are complex.  We don't have to build the tools such as 
dcopidl; we can happily fail if they're not there.  All our optional 
library dependencies are fairly straightforward ones that can be 
handled with nice easy HAVE_ flags, with the sole exception of ALSA.

> But the transparent handling of uic, moc, and dcopidl are something
> I'm not too keen on re-inventing, for instance.

Why not?  Apart from uic, they're all handled by my reorganise-makefile 
already in a handful of lines.  About the same amount of work again to 
detect whether the programs themselves exist, and you're done.

I can understand why we didn't start out with a simple 
autoconf/Makefile.in system when we first began, because the KDE 
situation was rather in flux, none of us had ever used autoconf for 
real, and we just didn't have much clue.  But if some angel had come 
along and made such a system for us, we'd probably still be using it 
quite happily.  Our problems with autotools (apart from actually using 
automake and libtool instead of just autoconf) had a lot to do with 
that big morass of scripts in kde_admin/ that nobody wanted to touch 
and that KDE ultimately abandoned.

Then our switch to scons has hardly been a success -- if it had been, we 
wouldn't be planning to switch again a year and a half later.  Again, I 
don't see scons itself as the problem, but bksys, a big morass of 
scripts designed for building KDE and then rejected by KDE and 
abandoned.  Are you sensing a theme here?


Chris

On Monday, 6 November 2006 20:49, Pedro Lopez-Cabanillas wrote:
> On Monday, 6 November 2006 20:27, Chris Cannam wrote:
> > I was intending to refer to a single CMakeLists.txt and a single set of
> > cmake generated files instead of one per directory.  i.e. still using
> > cmake, but without the plurality of makefiles.
>
> Ah, OK. I will try this approach. Also, to have a single CMakeLists file
> using some auxiliary small files, for better maintainability.

After thinking again about this, I come across another proposal.

- One CMakeLists at root level, with all the checks for 3rd party libs. The 
generated makefile should invoke:
	- scripts to build and install i18n files (po/ directory)
	- scripts to build and install docs/ directory
	- install files in data/ directory. 
	- uninstall and distclean custom targets (any others?)
	- recurse into src/ directory for applicable targets

- A second CMakeLists at src/ to build and install two targets (our two 
executables) without building any intermediate libraries. It may use wildcard 
discovery of sources, or include external lists of source files. I don't like 
automatic source lists, because it may include things like the guitar test  
files, and other sources which could be avoided for usual builds. Also for 
special builds (as a "nosound" option) it would be better to have explicit  
lists of sources.

I have very little free time at labour days, sorry. I hope to do some work on  
this next weekend.

Regards,
Pedro

On Tuesday, 7 November 2006 04:30, D. Michael McIntyre wrote:
> I rather like it, I must say.  It looks and feels solid.  Cons for scons
> other than abandonment, the damn thing always felt like we just barely had
> it working with the right combination of duct tape and kite string.  There
> was some weirdness with the LIRC dependencies always getting checked on
> every build, and all manner of assorted other vague and niggling things
> that never inspired a lot of confidence.

Most problems came from the fact that scons is a replacement for make, and not 
for the autotools. The hole was filled by bksys, which had some problems. But 
for me, the most irritating one was from scons: the damned and infamous 
"scons -c", combining the clean and uninstall functions in a single command. 
Please help me with a big English swear at it.

Regards,
Pedro

On Tuesday 07 Nov 2006 21:03, Pedro Lopez-Cabanillas wrote:
> scons: the damned and infamous "scons -c", combining the clean and
> uninstall functions in a single command.

?!

Does it really do that?  I have never, ever noticed.


Chris

On Tuesday, 7 November 2006 22:26, Chris Cannam wrote:
> On Tuesday 07 Nov 2006 21:03, Pedro Lopez-Cabanillas wrote:
> > scons: the damned and infamous "scons -c", combining the clean and
> > uninstall functions in a single command.
>
> ?!
>
> Does it really do that?  I have never, ever noticed.

Yes. There is not an uninstall target, instead you must use:

	$ scons -c install

Which not only uninstalls, but also cleans the build tree. From "man scons":

       -c, --clean, --remove
              Clean  up  by removing all target files for which a construction
              command is specified.  Also  remove  any  files  or  directories
              associated  to  the construction command using the Clean() func-
              tion.

Regards,
Pedro

On Tuesday 07 November 2006 4:03 pm, Pedro Lopez-Cabanillas wrote:

> problems. But for me, the most irritating one was from scons: the damned
> and infamous "scons -c", combining the clean and uninstall functions in a
> single command. Please help me with a big English swear at it.

Yeah, definitely.  What a brain damaged stupid fucking pile of maggot-infes=
ted=20
monkey shit that was!  (Per your request, se=F1or. :) )

As far as all of that goes though, I have to say the scons Python thing was=
=20
probably the most approachable as far as adding a new file without learning=
 a=20
new language.  I don't know how it worked, but I don't know how any of it=20
works.  I grew up on Borland tools, and never wrote a Makefile.

reorganise-makefile is short, but I can't really tell you what the hell it=
=20
says.

Same thing with the CMakeLists.txt file and the various autoblither.in|am=20
gobbledegook.  It's all completely opaque and indeciperable.

Hell, I guess based on this requirement, my vote would be to build the fuck=
er=20
with a bash script.

=2D-=20
D. Michael McIntyre=20

Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/
See my new music stand unfolding at http://users.adelphia.net/~silvan/

On Tuesday 07 November 2006 20:56, Chris Cannam wrote:
>
> That's what I was saying, but perhaps my sarcasm was missed.  My point
> was that if the KDE project can choose a system on its merits for their
> use, why can't we?

We neither have the weight, nor the manpower :-).

> > But the transparent handling of uic, moc, and dcopidl are something
> > I'm not too keen on re-inventing, for instance.
>
> Why not?  Apart from uic, they're all handled by my reorganise-makefile
> already in a handful of lines.  About the same amount of work again to
> detect whether the programs themselves exist, and you're done.

Famous last words...

Back in our early days, when I first tried to add a DCOP interface to RG, it 
took me about half an hour to do it, even though the available doc was pretty 
sparse. It was sparse, but sufficient, because all it said was "add this and 
that in your .h file, and the build system will do the rest". The rest being 
calling dcopidl, compiling the results, etc... Gathering all this info and 
reimplementing it would have been a chore. If we want to turn our editors 
into kparts, using KDE's build system will help in the same way.

So I'm pretty sure that coming up with our own build system will be a decision 
we will regret.

> scripts designed for building KDE and then rejected by KDE and
> abandoned.  Are you sensing a theme here?

Actually, KDE rejected scons because of scons itself, not of bksys, and the 
adoption of scons never was as firm a thing as autoconf was. Had the scons 
dev team be more responsive, cmake wouldn't have been considered. But their 
dev team and the KDE guy pushing for it were making great progress, while 
scons turned out to be a dead-end for various reasons (dependencies 
computation taking too long, if I recall correctly).

-- 
Guillaume.
http://www.telegraph-road.org