Re: [Swig-devel] cvs status

[William S F. <ws...@fu...>]

William S Fulton wrote:
> Marcelo Matus wrote:
>> William S Fulton wrote:

>>> #error behaves like #warning, it produces a warning. Surely it should
>>> halt swig in its tracks?
>>>
>> ah, there is an option to do that, -nocpperraswarn. The problem appears
>> for example with subversion. They wrap directly a library file, "apr.h",
>> which requires platform dependent macros or else, it sends an #error.
>>
>> so, before we implement #error, swig compiles the apr.h file with no
>> problem and everyone was happy since the #error directive was ignored, 
>> well
>> except that some portions/macros in the file were ignored, but everyone
>> was happy with that.
>>
>> Once #error get implemented, then swig fails to compile the file, unless
>> you provide all the missing macros that the file was requesting.
>>
>> And given that that could be the case with many other interfaces that
>> just include preexisting header files with the previously ignored #error
>> directive, now swig still recognize #error but it uses the -cpperraswarn
>> mode by default, ie, it sends an specific warning to the output, which is
>> different from the one you get from #warning. So, you will see the #error
>> warning even if you disable the #warning code. And also you can disable
>> the new "#error" warnings as any other warning.
>>
>> But, if you still want swig to crash as cpp, you can use the 
>> "-nocpperraswarn"
>> option.
>>
> Mmm, okay then.
> 
> 
>> See the mailing list for more discussions about this issue.
>>

I've been thinking about this a bit more and would like to discuss 
further. I'm not sure that making #error behave as #warning by default 
is correct or expected behaviour. The preprocessor should behave like a 
C preprocessor and halt. If the subversion programmers are coding #error 
as a #warning, then surely they should use #warning instead or use the 
new swig -cpperraswarn commandline option. SWIG-1.3.27 changed earlier 
behaviour by no longer ignoring #error, so although this is a change 
from earlier versions, surely by default we should keep consistency with 
1.3.27 and all C/C++ compilers?

William