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