Re: windres handles #include suffixes?

[Fred Cooke <fred dot cooke at gmail dot com>]

My 2c:

Trivial custom format patch:

- /* Whether we are supressing lines from cpp (including windows.h or
-   headers from your C sources may bring in externs and typedefs).
+ /* Whether we are suppressing lines from cpp (including windows.h) or
+   headers from your C sources (which may bring in externs and typedefs).
? When active, we return IGNORED_TOKEN, which lets us ignore these
? outside of resource constructs. ?Thus, it isn't required to protect
? all the non-preprocessor lines in your header files with #ifdef
? RC_INVOKED. ?It also means your RC file can't include other RC
? files if they're named "*.h". ?Sorry. ?Name them *.rch or whatever. ?*/

Maybe my fix is wrong, but the original sentence is not well formed English.

"This assumes that files with a relative pathname are user generated
resource files and do not include C syntax, whereas files with an
absolute path are system generated and do include C syntax."

This ^ sounds like a dangerous and confusing assumption?

"Hmm, this may not always be true however." +1

Regards,

Fred.

On Wed, Feb 29, 2012 at 12:33 PM, nick clifton <nickc@redhat.com> wrote:
>
> Hi Alon,
>
>
>> But this is a strange behavior, no?
>
>
> It is rather. ?But it is definitely explicitly coded this way. ?See the start of the binutils/rclex.c file where it describes the 'suppress_cpp_data' variable in a comment which reads:
>
> /* Whether we are supressing lines from cpp (including windows.h or
> ? headers from your C sources may bring in externs and typedefs).
> ? When active, we return IGNORED_TOKEN, which lets us ignore these
> ? outside of resource constructs. ?Thus, it isn't required to protect
> ? all the non-preprocessor lines in your header files with #ifdef
> ? RC_INVOKED. ?It also means your RC file can't include other RC
> ? files if they're named "*.h". ?Sorry. ?Name them *.rch or whatever. ?*/
>
> The strange thing is that nowhere in the code or documentation does it explain why this behaviour is necessary. ?I suspect that the designers found that it was too complicated to add support for scanning C header files when all they wanted to do was process windows rc file syntax. Hence their decision to silently ignore #includ'ed files with a .h suffix.
>
>
>
>> BTW: is this the same with MSVC? I almost sure MSVC handles all data.
>
>
> If you can show that MSVC does do this then we will have to fix windres. ?On the other hand if MSVC behaves in the same way as windres, then you will need to modify your build environment instead.
>
> Assuming that you can show that MSVC includes .h files, please could you open a bug report for this problem here:
>
> ?http://sourceware.org/bugzilla/
>
> I have a possible patch for the bug, which allows #include'd .h files to be processed provided that their pathname does not start with a forward slash. ?This assumes that files with a relative pathname are user generated resource files and do not include C syntax, whereas files with an absolute path are system generated and do include C syntax. ?Hmm, this may not always be true however. ?I may need to add a command line switch to restore the old behaviour of ignoring all .h files.
>
>
>
>> When I am force to have .rc suffix, it is harder to control the
>> implicit rules...
>
>
> You could always use a .rch suffix.
>
> Cheers
> ?Nick