Bob Rossi wrote:
> On Wed, Aug 29, 2007 at 07:39:50PM -0700, Robert Roessler wrote:
>> Mr Philip (and Bob and Daniel), I am unhappy to see the PCRE project
>> head in the direction of more complexity in the build environment for
>> little (if any) gain (obviously MY opinion)... but seriously, even if
>> there is no concern for Windows at all (which doesn't seem to quite be
>> the case), switching away from a structure which could be trivially
>> built with only a make and a compiler (or an IDE handling both
>> functions) doesn't make a whole lot of sense from an engineering
>> standpoint, does it?
>>
>> Yes, I *can* still build it with Visual Studio 2005 (which does happen
>> to include a serious and high-quality C/C++ compiler), but the
>> underlying model seems to be going more and more to requiring/assuming
>> you are *of course* using auto-this and auto-that... and the answers I
>> received from Bob and Daniel reflect that (but I am still appreciative
>> of the time it took to give them).
>>
>> It's not like we are trying to build an operating system (or a Mozilla
>> FireFox) here... PCRE has historically been a clean, contained
>> *library*, without exotic build requirements (or the mindset that goes
>> with them), and it somehow managed to become an influential building
>> block in lots of software nonetheless... :)
>>
>> OK, semi-rant-mode OFF (well, mostly).
>
> Robert,
>
> Please, calm down.
OK. Deep breaths taken.
> It was decided to move pcre to the autotools build system so that you
> could build it on many platforms, in many different configurations,
> and users of pcre could do this _easily_.
>
> It was also decided to add the CMake build system, (which I know nothing
> about), so that pcre users could build pcre _easily_ on platforms when
> used cl (and other compilers?).
>
> So, the point is, to make your life easy. Instead of complaining, why
> don't you describe why your life is not easy, and we'll attempt to make
> it easy again.
I think one of the things I strongly disagree with is this "we're doing
it to help YOU"... when there was never anything like an attempt to
reach out to known users of PCRE, just by say, harvesting Mr Philip's
email history, or at least, an announcement on the site inviting
discussion/comments that would have been left there for 30-60 days.
The changes are all in the direction of making a simple system more
complex (and with more pre-requisites), which I would think should make
any experienced software engineer look askance (maybe more than once).
Certainly, anything which made Mr Philip's life easier in terms of
maintenance and distribution would automatically have something in its
favor, BUT...
How does not only taking a clean, simple, SINGLE include of config.h
(with or without the proper language-intended construction - "" vs <>),
and transforming that into twenty-odd points of failure or confusion (do
I need this here? hmmm...), but now the includes themselves don't even
HAPPEN without defining a mysterious symbol which isn't ever mentioned?
Not to mention the fact that forever after (unless this "improvement"
is rescinded in a timely fashion), every new source file added to PCRE
forever will now need to also have this gratuitous and bizarrely
expressed include.
This seems like a losing proposition from any and all of the
perspectives of ease of use, reliability, maintainability, and just
simple code clarity/transparency.
And how does ANY of this large set of changes make life easier (or even
as good as it was) for users of one of the more popular toolchains on
the dominant operating system on the planet? The point is not so much
that there are not solution/project files for any version of Visual
Studio (I can certainly contribute those), but that clearly the concerns
of this portion of the developer population don't seem to be very well
represented... if they were even considered at all.
> Maybe it is possible you could contribute a Makefile.static makefile
> that would build pcre as a static library. It could contain a bunch of
> simple commands to do this.
My own uses don't include anything quite this simple.
>> And then there is the changing of other symbols like PCREPOSIX_STATIC in
>> 7.2 becoming PCRE_STATIC in 7.3? Things like this make life harder for
>> the consumers of PCRE, and what did it buy?
>
> What about changing the symbol PCREPOSIX_STATIC -> PCRE_STATIC made your
> life harder?
Pretty straightforward, actually - as would be the case with pretty much
any use of PCRE that includes redistributing PCRE as a component of some
package, one likes to support as many different releases of PCRE as
possible, to give one's ultimate consumers the flexibility to select a
version of PCRE that meets *their* needs (possibly extended formalized
testing, just plain better comfort level from experience with a
particular release, etc).
ONE of my two major uses of PCRE involves shipping an Objective Caml
binding for [the POSIX form of] PCRE in a single package that is
buildable on Windows OR *nix platforms - all controlled with a
reasonably simple makefile. To digress, my approach to this is to have
them expand the PCRE distribution of choice *somewhere* and then point
to it with make vars from wherever they have expanded my package - I
then use VPATH in the makefile to actually reference the PCRE source.
Anyway, back on point, life is already complex enough in this
environment, because version to version, there have been changes that
force me to have conditional paths in the makefile to define or not
define symbols that the PCRE source now wants / doesn't want... one of
my personal favorites was the abrupt shift of the default build mode of
PCRE [posix] from static lib to DLL (back in the 6.x days?). ;)
So every time that some change like "PCREPOSIX_STATIC -> PCRE_STATIC"
happens, it means I have to notice that it happened (since it probably
hasn't been pointed out in a changelist), code a new path in the
makefile to deal with it (adding a possible point of failure), and now
my testing task has just gotten larger.
>> I know it is quite unlikely, but *maybe* some of the changes that went
>> into the [unfortunate] 7.3 release could be carefully reviewed - and the
>> ones that aren't bugfixes reversed? I would be happy to do the edits... ;)
>
> What makes you think that they were not carefully reviewed?
> What exactly would you like reversed?
See above... at the least, the whole new and improved handling of
config.h just doesn't seem conscionable when one steps back and looks at
real software life-cycle costs.
I am getting the idea that even with my two wildly different uses of
PCRE (Windows-only using the Visutal Studio IDE, as well as a
cross-platform source-based release for *nix AND Windows systems), I am
somehow not being *perceived* as your target demographic (if such
terminology is meaningful here)... OK, a bit of sarcasm. :)
But, allow me to make my penultimate point: while I will admit this is a
home-grown idea (it came to me during this sequence of communications),
it strikes me that when shipping open-source projects, it is in the
interests of the project's *consumers* for the *developers* to extend
the concept of "interface"... so that ideas like contracts and expected
invariants include the externally visible aspects and controlling inputs
to the build process.
In case this seems too tortured, I am trying to draw an analog between
all the reasons we expect adherence to an *interface* to make changing
*implementations* safe and easy, to having a package maintain
[obviously, as much as possible] an unchanging build methodology for all
things observable.
So, I am saying that the same things should be done when breaking these
observable aspects of the build process as when we decide that a [gasp,
sacred] interface be changed: do we REALLY need to do this, are the
intended beneficiaries us or our consumers (both can be valid - or not),
have we left the old "interface" in place for those whose needs are
already being met perfectly adequately, and if the answer is NO for this
last question, then have we been very upfront and open with our
consumers about WHY we made this choice, WHAT it will do for them, and
HOW they manage to keep using our product without everything they use it
in being BROKEN.
To wrap up, my philosophical backing on simplicity in engineering comes
from Albert Einstein: "Everything should be made as simple as possible,
but not simpler."(*) It seems like we differ substantially on where
that break is.(**)
(*) - a more modern variant of this might be: KISS (Keep It Simple,
Stupid). ;)
(**) - still trying to communicate: the original authors of Unix had, as
one of their cool ideas, the thought that while a tool might do wondrous
and complex things (requiring wondrous and complex specification of
controlling options), as a DEFAULT it should do something USEFUL. I
submit that re-structuring these silly includes such that they DON'T
happen at all (even though they are absolutely required) without a
magical extra define appearing on every compile command line (documented
or NOT)... completely disregards this time-proven concept.
Robert Roessler
robertr@r
ftp.com
http://www.rftp.com
