[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] CMake build system: some proposed changes
From: |
Werner LEMBERG |
Subject: |
Re: [ft-devel] CMake build system: some proposed changes |
Date: |
Wed, 26 Jun 2019 09:23:46 +0200 (CEST) |
> I've been looking at some CMake issues filed over at Savannah. One
> ting that pops up in a few places is that some people do not expect
> CMake to autodetect external dependencies, which can lead to
> problems when e.g. baking packages for distribution.
Having switches for all external dependencies sounds OK. Being not a
CMake user I don't know what Joe User expects (see concerns raised by
Alexei).
> I don't have a strong opinion on this and tried to find "best
> practices" on this in the CMake world, but didn't get much of
> anything resembling, well, anything useful. Maybe it's just the
> CMake world being as anarchic as usual. Or maybe I didn't put in
> enough effort.
Hehe.
> My idea: implement knobs for all (?) ON/OFF options listed in
> ftoptions.h and make their default state mirror the default state in
> ftoptions.h.
This sounds like overkill. There are many options that will never be
touched by Joe User.
> This would also mean external dependencies are off by default.
Mhmm, this doesn't sound nice. I think that auto-detection is a good
thing.
What about making cmake emit a report after execution, similar to the
`configure' script, which also lists the cmake CLI options to switch
the corresponding features on or off?
> I will not change the default build system. The idea is that you
> configure freetype2 the "idiomatic" CMake way, instead of fiddling
> with ftoption.h yourself.
After cmake execution a hint could be printed that guides people what
to do if further tweaks are necessary. Similarly, the options in (the
generated version of) `ftoption.h' that are controlled by cmake could
be marked as such with a comment like
/* handled by cmake, don't change manually */
so that users are not confused.
Werner