Bugzilla Bug 190981

<snip>
/usr/portage/eclass/php-ext-pecl-r1.eclass:27: PHP_EXT_PECL_PKG: unable to
extract default variable content: 
/usr/portage/eclass/php-ext-pecl-r1.eclass:36: PHP_EXT_PECL_FILENAME: unable to
extract default variable content: 
/usr/portage/eclass/php-ext-pecl-r1.eclass:40: DOCS: unable to extract default
variable content: 
</snip>

What's this trying to say? Sorry but I don't grok it. The eclasses are in CVS
now, could you tell me what's it moaning about?

----

</snip>
/usr/portage/eclass/java-ant-2.eclass:26: Unexpected tag in "header" state: #
@variable-preinherit WANT_ANT_TASKS
/usr/portage/eclass/java-ant-2.eclass:27: Unexpected tag in "header" state: #
@variable-default ""
/usr/portage/eclass/java-ant-2.eclass:33: Unexpected tag in "header" state: #
@variable-preinherit WANT_SPLIT_ANT
/usr/portage/eclass/java-ant-2.eclass:34: Unexpected tag in "header" state: #
@variable-default ""
/usr/portage/eclass/java-ant-2.eclass:43: Unexpected tag in "header" state: #
@variable-preinherit JAVA_ANT_DISABLE_ANT_CORE_DEP
/usr/portage/eclass/java-ant-2.eclass:44: Unexpected tag in "header" state: #
@variable-default unset for java-pkg-2, true for java-pkg-opt-2
/usr/portage/eclass/java-ant-2.eclass:83: Unexpected tag in "header" state: #
@global JAVA_PKG_BSFIX
/usr/portage/eclass/java-ant-2.eclass:93: Unexpected tag in "header" state: #
@global JAVA_PKG_BSFIX_ALL
/usr/portage/eclass/java-ant-2.eclass:102: Unexpected tag in "header" state: #
@global JAVA_PKG_BSFIX_NAME
/usr/portage/eclass/java-ant-2.eclass:111: Unexpected tag in "header" state: #
@global JAVA_PKG_BSFIX_TARGETS_TAGS
/usr/portage/eclass/java-ant-2.eclass:120: Unexpected tag in "header" state: #
@global JAVA_PKG_BSFIX_SOURCE_TAGS
/usr/portage/eclass/java-ant-2.eclass:129: Unexpected tag in "header" state: #
@global JAVA_ANT_IGNORE_SYSTEM_CLASSES
/usr/portage/eclass/java-ant-2.eclass:137: Unexpected tag in "header" state: #
@private java-ant_bsfix

...
</snip>

$ grep @ECLASS /usr/portage/eclass/java-ant-2.eclass
$

Why's it even trying to parse this, flooding people with bogus warnings?

there are no bogus warnings ... the awk tries to extract the default value to
display it in the manpage but the way you've written the eclass prevents that
from happeneing

OMG, are you joking or what? *What's* preventing the eclass from being parsed?
What kind of default value? Could you finally answer that simple question? 

And why is it parsing eclasses it should NOT parse at all since there's no
@ECLASS at all in the first place?

comment blocks are supposed to appear before the default variable setting so
that the default value can be extracted and displayed

if it doesnt, you get a warning, and the manpage does not display the default
value

(In reply to comment #3)
> comment blocks are supposed to appear before the default variable setting so
> that the default value can be extracted and displayed
> 
> if it doesnt, you get a warning, and the manpage does not display the default
> value

Please, don't try to do impossible things in the script. If there's a default
value, it's up to the eclass to document if desired, instead of performing
broken black magic somehow via the awk script.

Now, what's the thing with trying to parse java-ant-2.eclass,
java-utils-2.eclass, java-vm-2.eclass, webapp.eclass? This script's acting like
a bull seeing a red cloth whenever it hits @ character.

if you dont want your var documented, then ignore the warning

(In reply to comment #5)
> if you dont want your var documented, then ignore the warning

Apparently asking two questions at a time doesn't work... let's try again then:

<snip>
What's the thing with trying to parse java-ant-2.eclass,
java-utils-2.eclass, java-vm-2.eclass, webapp.eclass? This script's acting like
a bull seeing a red cloth whenever it hits @ character.
</snip>

The script fails to ignore eclasses that have no @ECLASS tag there, spewing the
users with hundreds of irrelevant warnings. Can we get this fixed please?

fix the eclass

(In reply to comment #7)
> fix the eclass

Yeah, clearly asking for the script to behave consistently and ignore eclasses
unless it contains "@ECLASS: " (and exactly that, with exactly that case and
nothing else containing any substrings of that) is mission impossible. Even if
the java eclasses get "fixed", the script will still be broken because
webapp.eclass doesn't contain any @ECLASS variant at all, yet it causes the
same issue, because it contains other things with @ which trigger the awk
script misbehaviour. 

I might suggest that people should think about design before writing up
something, as @ apparently plain sucks as a tag (a quick grep through the
existing eclasses would have shown this at the very beginning) - but at this
point I plain don't care enough any more, wasted enough time on this broken
script that's spamming users with junk.