In regard to: Re: guile 1.3.4 & CVS: build problem on alpha-dec-osf (fix...:
>Thank you for finding this bug!
>
>Tim Mooney <[EMAIL PROTECTED]> writes:
>
>> One possible fix would be to move the #include "libguile/tags.h" to much
>> nearer the top of __scm.h, but I think that's just putting the problem off,
>> rather than really fixing it. It will allow the build to procede, but who
>> knows if a similar but even harder to trace problem will pop up on some other
>> system down the road, because of the "include jungle".
>>
>> My humble suggestion is that `random.h' is an unfortunate name for a local
>> header file, even one that is referenced as "libguile/random.h".
>> Looking over the other header files that get installed in libguile, there
>> are a few others that probably shadow system header files on any number
>> of systems.
>>
>> The most bullet-proof solution for the problem would be to rename many of
>> the header files, especially the ones that will be installed as part of
>> a `make install', so that they have a unique prefix, e.g. `guile_'. This
>> would give you things like `guile_random.h', `guile_tags.h', etc. You would
>> want to rename the header guards (#ifdef RANDOM_H becomes #ifdef
>> GUILE_RANDOM_H) and you would need to change all the files that include these
>> header files, but it does have the best chance of fixing the problem once and
>> for all.
>
>I'm not fond of the idea to use strange names for the guile header
>files. The prefix "libguile/" *should* be enough. It will be enough
>if we always reference Guile header files using libguile/... and
>don't pass -I .../libguile to GCC, right?
If you keep header files with names like `random.h' in the libguile directory,
you would need to be certain that `-I.' was never used while compiling
anything in that directory. You would likewise need to be certain that
`-Ilibguile' was never used in the top directory and `-I../libguile' was
never used in any sibling-directories of libguile. All that may break
other things, or it may not. The problem is that it's a "brittle solution",
meaning that it may solve this problem, but a similar problem may pop up
again later.
I don't think there's any harm in trying what you suggest -- make the
easiest change first, and see what that does. I'm just concerned that
it's just changing the situation under which the problem occurs, rather
than fixing the problem completely.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
