lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] wx ./configure options


From: Vadim Zeitlin
Subject: Re: [lmi] wx ./configure options
Date: Sat, 27 May 2017 13:38:47 +0200

On Sat, 27 May 2017 10:44:32 +0000 Greg Chicares <address@hidden> wrote:

GC> One change that I think shouldn't matter to you is to add
GC>   --enable-no_deps
GC> However, does that actually have any effect?

 No, apparently this option was lost/broken for the last 14 years, since
the switch to bakefile-generated makefiles in 
fe0895cf82381b91113de34a32b0bcf9bdef98a7
I could make it work identically to --disable-dependency-tracking, but I
don't think it's worth doing this because this option is badly named (just
what exactly --disable-no_deps is supposed to do?) and nobody seems to be
using it, so I'd rather remove it instead.

 But, just to restate it more explicitly, you can use
--disable-dependency-tracking instead.

GC> [BTW, is there any way I can easily see which options were ignored?
GC> On my first attempt, I mistakenly used this:
GC>   --enable-enable-no_deps
GC> and I didn't find an error message diagnosing my mistake.]

 For some reasonable but still annoying reasons, configure doesn't check
--enable-xxx and --with-xxx options validity by default. This, however,
can be explicitly enabled with --enable-option-checking=fatal and I think
it would be a good idea to do it by default (you would still be able to use
--disable-option-checking if really needed, e.g. if you wanted to pass some
options not recognized by the main configure script to tiff or expat
configure which is run by it if the corresponding system library couldn't
be found).

GC> Is there a way to inhibit PCH?

 Yes, using --disable-precomp-headers (it's in configure --help).

GC> Should we be using either or both of the following C++11 options?
GC>   --enable-cxx11
GC>   --with-cxx=11

 In principle, there is no need to build wxWidgets using C++11 with gcc as
it's nice enough to preserve compatibility between C++98 and C++11 code and
currently wx doesn't use any C++11 features internally. If you do prefer to
build all code using the same options, e.g. to avoid running into any of
the issues listed at https://gcc.gnu.org/wiki/Cxx11AbiCompatibility (at the
first glance, none of them seem to be applicable, but who knows...), then
just one of those options should be used (i.e. using both is useless).

 The difference between them is that --enable-cxx11 will use C++11 if it's
available, but fallback to C++98 otherwise, while --with-cxx=NN will
require support for C++NN and abort configure if it's not available. For
lmi they're equivalent as all compilers we use do need to support C++11
anyhow, but I'd use --with-cxx=11 for clarity (again, assuming we want to
build wxWidgets in C++11 mode at all).

GC> Isn't the first of these two options:
GC>   --enable-std_iostreams \
GC>   --enable-stl \
GC> implied by the second, so that the first may be removed?

 Yes.

GC> Currently I'm specifying
GC>   --disable-compat24
GC> which I think is silently ignored.

 Yes, but it won't be after my changes mentioned above, so it would be
better to remove it now. This option disappeared in wxWidgets 3.0 according
to the usual rules: --enable-compatN version appears and is on by default
in N+2 release, becomes off by default in N+4 release and disappears (i.e.
becomes permanently off) in N+6 release.

GC> I'm guessing that the defaults for such 'compat' options are generally
GC> appropriate and should not be overridden without a specific reason.

 Defaults are determined by the rule above, but if you can afford it, it's
better to use --disable-compat(N-2) to ensure that no changes will be
needed when updating to the future versions. So the best would be to
actually replace --disable-compat24 with --disable-compat30.


 Other than that, I don't have anything special to say about the options
used. FWIW patent/licencing-related reasons for using --disable-gif don't
apply any more as the GIF patent has, finally, expired, but I guess you
still want to keep it for the same reasons you disable JPEG and TIFF
support. There certainly are other library features that could be disabled,
but I don't think it's really worth doing this.

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]