Compiling ports in a post-9.0-RELEASE world

[Matthias Andree]

Am 17.03.2011 14:07, schrieb Konstantin Tokarev:
>
>
> 17.03.2011, 15:39, "Konstantin Tokarev"<annulen at yandex.ru>:
>> 16.03.2011, 11:33, "Alberto Villa"<avilla at freebsd.org>;:
>>
>>>   On Wednesday 16 March 2011 09:15:07 Konstantin Tokarev wrote:
>>>>    From http://clang.llvm.org/docs/LanguageExtensions.html
>>>>
>>>>    "In addition to the language extensions listed here, Clang aims to
>>>   support
>>>>    a broad range of GCC extensions."
>>>>
>>>>    So GCC extensions may also be considered as missing features.
>>>   gcc-isms also means "bad code which is nonetheless supported by gcc"
>>
>> In this case don't hesitate to file a bug against gcc :)

Not necessarily.  If it's a documented extension that you'd allowed (and 
even by sticking to the implicit gnu89 language default of GCC) then 
you'll hardly hear back anything else than "invalid, works as documented".

> Let me elaborate my idea a bit.
>
> One may think that reporting bugs on GCC he supports development of
> technology that FreeBSD does not endorse [1]. I don't think so.
>
> 1) Latest versions of GCC are more standard-compliant than earlier ones,
> and bad written code tends to produce compilation errors with newer GCC.
> For example, I've seen lots of legacy code written for GCC 3.x but failing
> to compile with 4.x. 4.x branch is also being improved.

This is based on the implicit assumption that the code were to be 
compiled with -std=c99 -pedantic-errors [-Wall] or similar.  The 
majority of upstream packages doesn't follow such a purity paradigm, but 
knowingly or unbeknownst use -std=gnu89, and often GNU libc, extensions.

Documented extensions have NOT USUALLY gone away in newer GCC minor 
releases.

> 3) Projects with dead upstreams should be excluded from ports collection
> someday, unless maintainers are willing to do "upstream" job. Folks using

That's a separate discussion under the "deprecation campaign" subject. 
Please discuss that there.

-- 
Matthias Andree