Re: [Quantlib-dev] cmake configured files

[Jonathan S. <sw...@gm...>]

Hi Peter,

I can’t claim to 100% understand the way that the configuration works on
all the various platforms, but as far as I can tell the main reason for
still configuring qldefines.hpp in the CMake build is to let the user
choose between config.hpp and userconfig.hpp. When the QL_HAVE_CONFIG_H
CMake variable is set to true (which it is by default) then qldefines.hpp
is configured to include config.hpp, but when it is set to false then
qldefines.hpp is configured to include one of the platform-specific files
like config.msvc.hpp.

As far as I understand the history, the various config.*.hpp files along
with userconfig.hpp were basically a mechanism for enabling and disabling
different features before the CMake build came into existence. With CMake,
those features can be turned on and off more easily through build options.
On that basis, I’m not sure it makes much sense to expose QL_HAVE_CONFIG_H
to “opt-in” to the old way of configuring the build, but again I might be
missing some nuance.

My own opinion is that the CMake build should not overlap with any of the
older mechanisms like userconfig.hpp and should instead be implemented in
clean, standard, idiomatic CMake as much as possible.

Not sure if that answers the question but hope it helps.

Regarding the version, where is the other place it is maintained? I see
another version in configure.ac - is this the one you are referring to? Not
sure whether autoconf allows for reading a version from a file, but if it
does, then perhaps CMake could configure the version from the same file as
well.

Jonathan


2022년 5월 1일 (일) 01:14, Peter Caspers <pca...@gm...>님이 작성:

> Hey Luigi, Jonathan,
>
> I didn't follow all the cmake updates in detail so apologies if that
> was discussed before: Is there a reason why cmake configures
> qldefines.hpp? Couldn't we just define HAVE_CONFIG_H instead of
> QL_CONFIG_H in the top CMakeLists.txt and it would "just work" with
> the standard qldefines.hpp?
>
> Not directly related: We also configure version.hpp now. I have the
> slight feeling this could do more harm than good, since the version
> info has to be maintained at two places now?
>
> Thanks
> Peter
>
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>