automake-ng
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Automake-NG] [PATCH 4/4] [ng] cleanup: after enabling of subdir-obj


From: Akim Demaille
Subject: Re: [Automake-NG] [PATCH 4/4] [ng] cleanup: after enabling of subdir-objects unconditionally
Date: Fri, 8 Jun 2012 11:59:07 +0200

Le 8 juin 2012 à 11:47, Stefano Lattarini a écrit :

>>> @@ -5068,11 +5057,6 @@ sub check_gnits_standards
>>> #
>>> # Functions to handle files of each language.
>>> 
>>> -# Each 'lang_X_rewrite($DIRECTORY, $BASE, $EXT)' function follows a
>>> -# simple formula: Return value is LANG_SUBDIR if the resulting object
>>> -# file should be in a subdir if the source file is, LANG_PROCESS if
>>> -# file is to be dealt with, LANG_IGNORE otherwise.
>>> -
>>> # Much of the actual processing is handled in
>>> # handle_single_transform.  These functions exist so that
>>> # auxiliary information can be recorded for a later cleanup pass.
>>> @@ -5105,33 +5089,34 @@ sub lang_c_rewrite
>>>                    uniq_part => 'AM_PROG_CC_C_O per-target');
>>>       }
>>>    }
>>> -
>>> -  return LANG_SUBDIR;
>>> +  return;
>> 
>> Pretty useless.
>> 
> Nope: in perl, if you don't use an explicit 'return' at the end of a
> subroutine, the value of the last expression (whatever that might be)
> is returned:
> 
>    $ perl -e 'sub foo { my $x = "oops"; }; print &foo . "\n";'
>    oops
> 
> So the above return is actually needed -- automake dies of an internal
> error if it's not present!  Do you want me to add a comment to clarify
> this?

Yes, definitely.  I'd like to know more about the error actually.
It must be that the other side is actually expecting a value.
So IMHO, the caller should be fixed.

>> { 1; }
>> 
> As the Zen goes, "Explicit is better than implicit" :-)
> But I'll do the change if you insist.

I mostly agree with your Zen, but I strongly disagree that
it applies here.  Every single modern language, especially
functional ones, have the "return" unnecessary.  Consider
"return" as a means to break flow control, not as a means to
specify the returned value.

>>> +# Vala '.vapi' are a kind of header files as well, and should
>>> +# not be processed into compilation rules.
>>> + sub lang_vala_ignore
>>> {
>>> -    # Header files are simply ignored.
>>> -    return LANG_IGNORE;
>>> +    my ($directory, $base, $ext) = @_;
>>> +    return ($ext =~ m/\.vapi$/ ? 1 : 0);
>> 
>> No return, no parens.  etc.
>> 
> See above.  The fact that perl allows us to be obscure is not a good
> reason to be obscure.  Removing the return and the three-way conditional
> would seriously hurt readability IMO.

Not my opinion :)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]