tech-userlevel archive

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

Re: make: new modifyer :Y



> Thanks, that was exactly what I was missing -- an indication of what the
> letter 'Y' represents. I am much obliged. :-P

You said :Y is obscure, I just explained ;-) I don't _know_ what others
_think_. I see only things they write.

 >> :Y doesn't break backward compatibility.
 >> So, it cannot break an existing code.

> No, there are other make programs out there, and our make used to bring
> in some of their modifiers for compatibility.

As far as I know only 44bsd make and derivatives have "variable
modifiers", that is make(1)-s shipped with *BSD systems.  If you know
others let me know.

> Seriously, though, if you want to impose this upon us all (and I think
> that this "all" goes a lot further than any of the BSD operating
> systems), we'd need to have an idea of what it gains for us.

This modifier gives "us" code cleaness and better maintainability.  Now
almost all variables we have in pkgsrc and base are documented as
"unless it is YES" or "unless it is NO". This is bad, bad and bad
because besides variable name and knowledge aboyt it is a boolean
variable I have to remember "what is its default". What happens if
variables is undefined or set to an empty string? Another problem is
that we have a lot of 1/0 boolean variables (NOxxx in base), a lot
yes/no booleans (e.g. MKxxx) and a lot of defined/undefined boolean
variables (by mistake/lazyness?). This is yet another extra knowledge
that I personally don't want to remember. More over, our yes/no
variables are *not* always case-insensitive (I filled a PR about one
such variable in pkgsrc a few years ago, my bet is that there are
others). Finally we don't have a uniform way to set/change the default
value for the variable from a command line. How can we set PKG_DESTDIR
to "yes" (suppose it set to "no" by default) in pkgsrc?  Easily!

  "make target USE_DESTDIR=no"

or

  env USE_DESTDIR=no "make target"

How about defined/undefined booleans? In no way! Our PKG_DEVELOPER was such a
"special" variable for years before bad@ fixed this problem about a year
ago. All of the above is what I'd like to avoid.

> The commonly used notation for this kind of choice is "yn".
Well, I don't think :yn is better than :Y but if others prefer :yn, it
would be better than nothing.

> That doesn't translate to almost any other language - most of the
> germanic languages start the affirmative with a "j", and it used to be
> that the best thing to check on for anything multi-languaged was "!=
> 'n'".
See above about "what is the default" hell.

> Can't you just use a make definition?

> Script started on Sun Nov  6 14:36:19 2011
> [14:36:19] agc@netbsd-vm1 ~/y [13] >cat Makefile
> YES=[Yy][Ee][Ss]

> MKLOVE?=yes

> .if ${MKLOVE:M${YES}}

Yes, I can use this trick in my personal projects but boolean variables
are de factor fundamental requirements for program written in bmake. So,
in my opinion it is better to implement the check for true/false value
in a language, globally, in one place for ALL bmake-based projects like
NetBSD, pkgsrc, mk-c or whatever.

-- 
Best regards, Aleksey Cheusov.


Home | Main Index | Thread Index | Old Index