Re: PACKAGE_VERSION should not be renamed

[Patrice Dumas]

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