On Sun, Nov 12, 2023 at 11:05:18AM +0000, Gavin Smith wrote: > However, I doubt that it is justified to rename it. We know it is an > option, so what is the point of putting _OPTION on the end to get > PACKAGE_VERSION_OPTION?
I chose that way because I imagined that using PACKAGE_VERSION only for macros defined in config.h was a kind of established custom. But it is probably better to avoid this change as you mention. > This could be dealt with in a variety of ways. The most straightforward > would be to "#undef PACKAGE_VERSION" at the beginning of option_types.h. > That way, any source code file using the OPTIONS type and including > this file will not have that preprocessor definition active throughout > the file. > > We do not use the PACKAGE_VERSION from the build system for the XS code > and it simply has the value "0". (In the top-level build system, it is > the version of the package, currently "7.1dev".) I do not like that possibility that much, if we want to use PACKAGE_VERSION later on (we use it in perl code), it will not be available, I think that it would be best avoiding that solution. > It's also not necessary that we use the symbol PACKAGE_VERSION in the XS/C > code to refer to this option, so could be renamed to o_PACKAGE_VERSION > as a special case if the #undef option does not work or is not appropriate > for some reason. It seems to me to be a better solution, I'll have a look at it if you don't. I think that it is part of generated code from perl data or a txt file, so it should probably be fixed at generation time. -- Pat
