Bob Rossi wrote:
> On Sun, Sep 02, 2007 at 11:14:49PM -0400, Daniel Richard G. wrote:
>> On Sun, 2007 Sep 02 18:54:41 -0400, Bob Rossi wrote:
>>> OK, so the CMake build environment is not ready and the users of pcre
>>> currently can only use the autotools build?
>> The CMake system is usable, but there are some corner cases / robustness
>> issues that need to be addressed. Sheri also encountered some trouble
>> installing CMake itself, which I'll have to try to reproduce.
>>
>> Certainly the CMake system is working in *my* environment, and it should
>> work for anyone already using CMake for building KDE et al. But of
>> course, I'm quite aware that the system needs to be [a little more]
>> bulletproof for first-time users like Sheri, given that CMake is not yet
>> universally deployed and used.
>
> Robert,
>
> Which build system for 7.3 are you using? I'm assumming the autotools
> build system is not adequate. Is the CMake build system?
Mr Bob... a week's worth of ranting, and it didn't come through that I
don't *use* "build systems" [without a gun to my head]? :)
For my "closed source" stuff, I use my own VS 6/2003/2005 project /
workspace / solution files. For my open source projects, I use a [gasp]
makefile... which clearly involves some tradeoffs, as noted by Mr Daniel
and yourself.
Certainly when building something of the complexity and requirements of
PCRE (a "clean" library building block), I vastly prefer a least common
denominator approach, as I have the best chance of the build completing
properly in the largest possible number of environments. Possibly of
equal importance, when things DON'T go as expected, examining the
evidence is fairly straightforward - stacks of [obvious, less-obvious,
and even hidden] metafiles are not required to determine the cause of
the failure.
You have mentioned CMake... I grabbed the current installer for Windows,
and had no trouble placing it on my XP SP2 dev box. Likewise,it seemed
to encounter no difficulty generating VS 8/2005 project files for me,
which did in fact build.
HOWEVER. While this very "configure"-like approach may be adequate for
some set of users, I don't quite see it ruling my dev box anytime
soon... ;) Philosophically, it may have superior underpinnings to the
auto*/configure camp, given that it doesn't start off with the
assumption that if you're not running a Unix derivative, you should pack
it in before starting.
But ultimately, I am less than satisfied with CMake - for *my* software
development use cases. In particular, it doesn't do the build(s) *I*
want: static, string pooling, inline intrinsics, for example. And while
some (if not all) of this can be accomplished by tweaking the
"CMakeLists.txt" file(s), this would be inappropriate for general
distribution, as it defeats the point of *having* a CMake (or
"configure") facility.
I DID eventually find the CMake "Templates" directory (not from pointers
in the docs or FAQ), and it looks like judicious changes to *some* of
these files might cause CMake to generate my desired style of builds -
but it was way too hard to ferret this out. And while admittedly, some
of my requirements are esoteric (OK, arbitrary), surely the
DLL/so/static choice should be something that is immediately visible
with flashing lights? Maybe this could be in the experimental
CMakeLists.txt that is distributed with PCRE?
> I have another thought. Would it be more helpful if pcre was compiled by
> someone with a windows machine and we put a binary up on the download
> site? That way, only a single person would need to go through the effort
> of comiling pcre for mingw, and that would be compatible with msft cl.
I am not sure who would be the intended beneficiary of this? I can
obviously do builds of PCRE in a variety of environments, so this is
probably for a hypothetical consumer of your package... superficially,
this appears to make sense.
BUT, even just for Windows and the msvc[-compatible] toolchain, you
would be faced with a combinatoric explosion (or at least more versions
than you would want to maintain):
static build
[just the one, which is why I like them so much]
DLL build
"old" DLLs (VS6 days)
"newer" DLLs (VS .NET 2002/2003)
"newer again" DLLs (VS 2005)
[no doubt changing again for VS 2007?]
And Release and Debug versions of all of these. :)
Mr Philip, Mr Bob, and Mr Daniel, I would like to thank all of you for
listening to my concerns over the past week and giving thoughtful
responses and suggestions.
Thank you,
--
Robert Roessler
robertr@r
ftp.com
http://www.rftp.com
