[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 02:18:59 -0700 |
Hi Derek,
> From: Derek Robert Price
>
> >>copy config.h.in to windows-NT/config.h.in
> >>foreach #define in windows-NT/config.h.in.in
> >> find corresponding #undef in windows-NT/config.h.in
> >> (if not present, print warning)
> >> replace line with current #define
> >>end foreach
> >>foreach #undef in config.h.in
> >> find corresponding #define or #undef in windows-NT/config.h.in.in
> >> (if not present, print warning)
> >>end foreach
> >
> >========================================
> >OK, the concept looks sound but there are problems in "./config.h.in"
> >that IMO can be worked out.
> >--------------------
> >This is a good example that needs elaboration:
> >
> > /* ... */
> > #undef FILESYSTEM_BACKSLASH_IS_FILE_NAME_SEPARATOR
> >
> > #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
> >
> >IMO conditional #define warrants special attention along the lines of
> >"windows-NT/config.h.in.in" saying something about
>
> No it doesn't. Reread my pseudo-code. I was very specific where I
> mentioned #undef and #define.
I don't advise giving me code (pseudo or real) without expecting
it *may* come out looking very different. What was provided was
very good and much appreciated.
Note file names I use here are values useable for builds other than
Windows and are used to illustrate such use. Final script implements
in manner that will be easy to tailor.
> 1. Again, the entire config.h.in is copied to
> windows-NT/config.h.in, including your conditional constructs.
This is out of order if implemented as stated. I plan:
1. Read "windows-NT/config.h.in" to:
1.1 Collect list of #define/#undef statements.
1.2 Report duplicate #define/#undef statements.
2. Copy "config.h.in" to temporary file "windows-NT/config.h.tmp"
while doing:
2.1 Collect list of #define/#undef statements.
2.2 Report duplicate #define/#undef statements.
2.3 Replace #undef with #define collected in Step 1.
3. Append optional "windows-NT/config.h.end" to temporary file
"windows-NT/config.h.tmp" and close temporary file.
4. Compare temporary file "windows-NT/config.h.tmp" to output
file "windows-NT/config.h" stopping on first difference.
> 2. #defines in windows-NT/config.h.in.in are search/replaced over
> #undefs in the new windows-NT/config.h.in with a warning if
> there is no #undef to replace.
> 3. #undefs in config.h.in without corresponding #defines or #undefs
> in windows-NT/config.h.in.in cause warnings. (Note that #undefs
> in windows-NT/config.h.in.in are ignored until this step. They
> are intended to be used to suppress warnings if config.h.in
> happens to ever contain a conditional with an #undef inside.)
"(Note..." in your Step 3 was very helpful. Thank you. I continue:
5. Sort lists from Steps 1 and 2.1 and issue warnings per your
Steps 2 & 3 using a single pass comparing both lists.
6. Replace output file with temporary file *only* if different.
> The rule I know that you might not is that if the configure script is
> going to set a #define (or not) at configure time, it will always be
> #undefined in config.h.in.
Definitely helpful. Thank you.
========================================================
Note tracking conditional nesting level is required to perform my
Steps 1.2 and 2.2 accurately as *helpful* developer aid.
========================================================
I believe we both know there's *no way* we can produce correct output
using the current "windows-NT/config.h.in" as input. Too much stuff
will be dropped that is *only* in "windows-NT/config.h.in" file.
I assume you have a plan for revising *something* and I'd appreciate
at least an outline. Perhaps I could contribute if I had a clue.
I'm bet hedging with my Step 3 for a "windows-NT/config.h.end" file
to hold the extra stuff until a better plan is revealed.
I'm bet hedging by copying #define/#undef statements and skipping my
Steps 1.1, 1.2, 2.1 and 2.2 when conditional nesting level > 0 until
the better plan is revealed.
If you're interested I can provide a set of Windows inputs that when
combined with "./config.h.in" will output a *substantially* identical
result to the current set.
========================================================
I'm going to start another thread to exchange the script as work in
progress. The Subject will be "Perl: config-h.pl - Draft".
========================================================
Thanks again,
> Derek
Conrad
- Questions: ./config.h.in & ./windows-NT/config.h.in, Conrad T. Pino, 2004/05/13
- Re: Questions: ./config.h.in & ./windows-NT/config.h.in, Derek Robert Price, 2004/05/14
- RE: Questions: ./config.h.in & ./windows-NT/config.h.in, Conrad T. Pino, 2004/05/14
- RE: Questions: ./config.h.in & ./windows-NT/config.h.in, Conrad T. Pino, 2004/05/14
- Re: Questions: ./config.h.in & ./windows-NT/config.h.in, Derek Robert Price, 2004/05/15
- RE: Questions: ./config.h.in & ./windows-NT/config.h.in, Conrad T. Pino, 2004/05/15
- Re: Questions: ./config.h.in & ./windows-NT/config.h.in, Derek Robert Price, 2004/05/15
- RE: Questions: ./config.h.in & ./windows-NT/config.h.in, Conrad T. Pino, 2004/05/15
- Re: Questions: ./config.h.in & ./windows-NT/config.h.in, Derek Robert Price, 2004/05/15
- RE: Questions: ./config.h.in & ./windows-NT/config.h.in,
Conrad T. Pino <=
- Re: Questions: ./config.h.in & ./windows-NT/config.h.in, Derek Robert Price, 2004/05/16
- RE: Questions: ./config.h.in & ./windows-NT/config.h.in, Conrad T. Pino, 2004/05/16