Re: SCons support in LilyPond

[Graham Percival]

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