------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1198
Summary: Making the CMake buildsystem independent of ./configure
Product: PCRE
Version: N/A
Platform: Other
OS/Version: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Code
AssignedTo: ph10@???
ReportedBy: steveire@???
CC: pcre-dev@???
>
>
>
> --- Comment #63 from Philip Hazel
> <ph10-v9/oYvjo+k2wa9SdKMSz+Q@???> 2012-01-13 14:57:58 --- On
> Fri, 13 Jan 2012, Zoltan Herczeg wrote:
>
>> I leave the decision to Philip, since this means an extra human step
>> before release. Hm... would it be possible to store the version info in a
>> single file and all build system would collect it somehow? I have to
>> admit I am not good at build systems so maybe this is not possible...
>
> Sorry, I haven't been paying attention here very well. Steve, the
> pcre.h.generic file was originally put into the distribution for the
> benefit of people who could not use "configure". It is built by the
> PrepareRelease script by doing a basic "configure" configuration, and
> then copying the resulting pcre.h to pcre.h.generic. In practice, all
> that this does is to edit these lines:
>
> #define PCRE_MAJOR @PCRE_MAJOR@
> #define PCRE_MINOR @PCRE_MINOR@
> #define PCRE_PRERELEASE @PCRE_PRERELEASE@
> #define PCRE_DATE @PCRE_DATE@
>
> I'm a CMake pre-novice as far as expertise goes, but I would not expect
> pcre.h.generic to be mentioned at all. So why is it present in
> CMakeLists.txt, I wonder? I see that it's there in 8.21, so this is not
> new.
It has been there since svn rev 137 (March 2007). Presumably, as you say, for
convenience.
>
> I've looked at your patch, but I don't like the presence of the SET
> commands for the version number etc. That's a second place where this
> data would have to be updated. I'd rather only have to remember to
> update one set of information
Understood, and I agree.
> , the one that's stored in configure.ac.
>
> I guess that's why the OP who created the CMakeLists.txt file chose to
> use pcre.h.generic.
>
> The problem here is that pcre.h.generic is not built regularly, and not
> stored in the SVN repo, so it isn't possible to checkout the sources and
> build using CMake without doing something. That's not good.
Agreed.
>
> It would be really good if Zoltan's suggestion were possible, that is,
> to keep the version information somewhere that all build systems could
> use.
>
> In the meantime, perhaps there is a way to fudge it. I could add to the
> ./configure script "cp -f pcre.h pcre.h.generic" and arrange for
> pcre.h.generic to be stored in the SVN. I don't like this messy
> approach, however.
Nor do I. If it's possible to build with CMake, it shouldn't require
./configure at all.
> Is there any way CMakeLists.txt could be made to fish
> the values out of the configure.ac file?
Yes, CMake could parse the values out of there.
However, it might make more sense to define them directly in pcre.h? Is there
any advantage to defining them in the ./configure stuff (I don't know anything
about that kind of buildsystem. There might be very good reasons).
> I think we need to think about this a bit. There *must* be a clean way
> of solving it.
>
Sure, I think at least it should be possible to parse it out of configure.ac.
If it makes sense to move the variables out of there into a separate file that
both systems can use, that's fine too. I'm happy to implement either one.
Thanks,
Steve.
> Philip
>
>
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
