[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SCons support in LilyPond
From: |
Graham Percival |
Subject: |
Re: SCons support in LilyPond |
Date: |
Sun, 11 Jan 2009 13:15:54 +0800 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Sun, Jan 04, 2009 at 11:48:10AM +0100, Jan Nieuwenhuizen wrote:
> Op zaterdag 03-01-2009 om 11:58 uur [tijdzone -0800], schreef Graham
> Percival:
>
> > I had great success converting another project to cmake last Aug,
> > but this isn't anything I'd attempt with my current situation. I
> > might propose it for 2.15 or 2.17 (next fall or sometime next
> > year), though.
>
> Hmm. Two years ago I had great success converting a cmake project to
> autotools. Maybe things have changed, but at the time some of my
> reasons to drop cmake were
>
> * used a home-grown MACRO language, which
> * was mostly undocumented (half-baken proprietary documentation in hardcopy
> was available) and buggy
I must admit that this is true. Their free docs are terrible, so
I learned most of their home-grown macro language from blog posts
and slideshows.
> * had nasty differences between builtin (c-made) and user-built macros
I think this was fixed in 2.6 -- it certainly wasn't an issue for
me.
> * had error prone dependency generation, one of the (at least) two reasons
> for
> * often leaving the build tree in a broken state after ^C
No problem there. I really liked their out-of-place build system,
too.
> * generates makefiles (adding an evil level of caching; one of the reasons
> for us to reject automake) that easily go stale (unlike automake: often
> unnoticed)
This was vital for our project; we needed a solution which
generated native build systems. On Linux we get makefiles, on OSX
we got makefiles or xcode projects (our choice), and on windows we
got MSVC projects.
> * mostly ignored common unix standards (not to mention GNU standards that
> LilyPond must provide) (clean/install/prefix/DESTDIR)
Isn't setting up the prefix done in configure? It's certainly
done in the cmake stage, rather than the "make" stage. As for
clean/install:
opihi:~/marsyas-autotest/testbuild/build marsyas$ make help
The following are some of the valid targets for this Makefile:
... all (the default if no target is provided)
... clean
... depend
... edit_cache
... install
... install/local
... install/strip
... list_install_components
... package
... package_source
... rebuild_cache
... test
... marsyas
> * had no provision for package-config to find libraries, but
> * used /usr/bin/find (instead of gcc-based tests) to guess/find libraries
> * used hard-coded /usr to start the search, making
I'm not certain about package-config, but in terms of the macros,
we use things like
find_path(VORBIS_INCLUDE_DIR vorbis/vorbisfile.h)
find_path(OGG_INCLUDE_DIR ogg/ogg.h)
find_library(OGG_LIBRARY NAMES ogg)
find_library(VORBIS_LIBRARY NAMES vorbis)
find_library(VORBISFILE_LIBRARY NAMES vorbisfile)
find_library(VORBISENC_LIBRARY NAMES vorbisenc)
Paths can be provided if necessary:
find_path(DSOUND_INCLUDE_DIR dsound.h
PATHS
"$ENV{DXSDK_DIR}/Include"
"$ENV{PROGRAMFILES}/Microsoft DirectX SDK/Include"
"$ENV{PROGRAMFILES}/Microsoft DirectX SDK
(August 2008)/Include"
DOC "The directory where dsound.h resides"
)
### as an aside, I cannot believe how sucky microsoft is. They
### seriously store libraries in filenames that include the DATE?!
### I mean, this isn't some random 3rd-party add-on; directX is
### pretty much a core library on windows!
> * cross compiling (instead of mostly automagic: autotools) next to
> impossible,
> and would also
> * barf when multiple versions of libraries are present below /usr
We never tried cross-compiling, and I can't recall whether we had
multiple versions of libraries present.
I'm not suggesting that cmake is appropriate for LilyPond, but I
think it must have improved in the recent past.
Cheers,
- Graham