bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Questions: ./config.h.in & ./windows-NT/config.h.in


From: Conrad T. Pino
Subject: RE: Questions: ./config.h.in & ./windows-NT/config.h.in
Date: Sun, 16 May 2004 14:35:50 -0700

Hi Derek,

> From: Derek Robert Price
> 
> This should be config.h.in.in or somesuch.  This script should be
> generating config.h.in which can later be processed by the build to
> substitute in the version numbers.  As mentioned earlier, the
> alternative is generating one of the source files for the script with
> the correct version numbers but I'd rather not do things in this order
> since configure can be editied and run by non-maintainers without
> needing Perl installed and this script will not be usable without Perl.

File names are not in dispute.  My previous message was an illustration
of names more suitable to builds other than Windows.  IMO illustrations
are not recommendations.  Neither am I recommending we stay with current
naming conventions.  Your proposal will do nicely.

I hedge bets when the total plan isn't clear and by that I mean I'm
keeping open the possibility of moving other builds towards a common
standard that may or may not exist and may or may not happen.

The extra checks are useful in examining the current inputs.  I expect
them to be useful during test phases.

In general your observing my preference for late binding i.e. reserve
options when feasible as insurance against the unexpected.

I'm not from Missouri but perhaps I would do well there. :)

Please be assured as we proceed with testing everything will fall into
place.  The bet hedges will disappear as *proven* test outcomes make
them obsolete.

> I wouldn't worry about multiple #defines in this file.  They would
> almost certainly be part of one of the conditionals we discussed earlier:
> 
> #if FILESYSTEM_ACCEPTS_DRIVE_LETTER_PREFIX
> # define FILESYSTEM_PREFIX_LEN(Filename) \
>   ((Filename)[0] && (Filename)[1] == ':' ? 2 : 0)
> #else
> # define FILESYSTEM_PREFIX_LEN(Filename) 0
> #endif
> 
> Anything that the configure script might define will exist only as an
> #undef in config.h.in.

These assurances are helpful and assuredly be heeded.  Eventually. :)

> to windows-NT/config.h.in...

Ditto above re file names.

> Hrm.  Sure.  Call it config.h.in.footer, though, please.  I think that
> is more consistent with usages elsewhere.

Done.

The idea of an optional header file occurred also.  I'll build it in
since it's cheapest to do it now while it's all fresh in my mind.

> I think you are getting way too complicated here.

Without a doubt but isn't it fun!!!  :)  On the serious side, yes
it's very hard thinking but if I don't do it then there's no joy.
There is an aesthetic there for everyone in those ones and zeros.

IIRC someone said not getting paid here.  The only other option is
take pleasure where it's found.

That Perl script may be overly spiced but I'm proud of it.

> There should be no
> nesting in windows-NT/config.h.in.in - we can control that, ...

I await the development of test data.

> ... and you
> should be able to search-replace any #undef in config.h.in with a
> define in windows-NT/config.h.in.in without a problem.

Agreed in principle.  I await the development of test data.

> ... You should be
> able to completely ignore any nesting since it simply won't happen,
> outside of the few conditionals you already spotted, and those will
> not contain any #defines for variables #undefed elsewhere.

I await the development of test data.
=====================================================================
IMO we're ready to test and don't have suitable inputs as yet.

I see these options:

1. You or an unidentified delegate provide the missing inputs.

2. I develop the missing inputs as your delegate at your direction.

3. I develop the missing inputs as your delegate at an unidentified
   third party's direction.

4. I develop the missing inputs to whatever specification I devise.
   Not the best option I would think but offered nevertheless in
   consideration of your and others time.

FYI:  Time becomes limited for me starting Monday.

I have other threads open regarding missing function prototypes.

All items I have open should be done quickly once a consensus has
formed on prototypes and test data is available for this issue.
=====================================================================
> Derek

Conrad





reply via email to

[Prev in Thread] Current Thread [Next in Thread]