Re: Suggestion: Modernization of the include path

[Sam Kendall]

On Tue, Jun 2, 2020 at 10:19 AM Paul Smith  wrote:

> On Tue, 2020-06-02 at 08:48 -0400, Sam Kendall wrote:
> > > I suggest that
> > > a) $HOME/.local/include is effectively added to the
> > >include_directories ...
> >
> > If two users build the same source tree, they will effectively be
> > building variants of it, each extending it with her own
> > $HOME/.local/include directory. And if one user builds two
> > *different* source trees, she will effectively add those same
> > extensions to both source trees, even if they were intended only for
> > one.
> >
> > Those are both bad results. I am strongly against this proposal.
>

Rereading this ... sorry, Christian; I didn't mean to sound rude. I'm just
making a technical argument.

I'm not sure I understand the concern here.
>
> Note that we're talking about default places to search for included
> makefiles, only; this isn't related to any locations that compilers or
> other tools invoked by make would search.
>

Understood. But it enables those included makefiles to do arbitrary other
things.


> GNU make already (as noted in the email) supports global directories
> for searching so adding a per-user directory seems logical and not new,
>  problematic behavior to me.
>

I've mostly worked in product development organizations with many
developers and with several OSes as build targets. I don't want to add
another magic (hidden) way that one developer's build can differ from
another's -- as in, "hey, my build is broken." "Okay, what's different
between your build and mine?" Over the years, the trend I've seen, and
encouraged, has been to reduce reliance even on global directories such as
/usr/local in favor of files that are in the source tree and so under
version control. User-specific include directories seem worse than global
directories in this regard.

 As far as I know, compilers don't provide user-specific include
directories; or if they did, I would be horrified if developers on shared
projects took advantage of them. And I see make and compilers as being in
the same class of tools.

--Sam

Re: Suggestion: Modernization of the include path

[Sam Kendall]

> I suggest that
> a) $HOME/.local/include is effectively added to the
>include_directories ...

If two users build the same source tree, they will effectively be building
variants of it, each extending it with her own $HOME/.local/include
directory. And if one user builds two *different* source trees, she will
effectively add those same extensions to both source trees, even if they
were intended only for one.

Those are both bad results. I am strongly against this proposal.

--Sam

Re: math expressions (was: Re: Tail call elimination)

[Sam Kendall]

I'd like to raise some questions that I think any proposal ought to answer.
I'll assume a straw man proposal: there's one function, and it takes one of
the following forms:

$(math OPERATOR,VALUE1,VALUE2)
$(math OPERATOR,VALUE1)

A binary operator (first form) is one of + - * and /. The only unary
operator is "-". There might also be equality and relational operators. A
value is an optional "-" followed by one or more decimal digits. It
represents a 64-bit signed integer.

I'd like to see a proposal that's as simple as possible and that includes
use cases. I also like fatal errors in dubious cases, because you can
always relax such a rule later and still be backward compatible.

---

Can an input include whitespace? If so, where?

What happens with an unparseable input such as empty string, foo, or 0.5?
Precedent suggests a fatal error. For example, any of those strings as the
first arg to $(word ) produces a fatal error.

What happens with an out-of-range input such as 9223372036854775808?

What happens upon overflow, e.g., $(math +,9223372036854775807,1)?

How do you input the most negative integer? In other words, is
-9223372036854775808 a valid value?

What happens upon division by zero?

What are the rounding rules for division?

If you have relational or equality operators, what does the boolean result
look like? If the result is 1 for true and 0 for false, then you get a bad
surprise: $(if $(math =,5,6),yes) expands to yes. If the answer is some
nonempty string for true and empty string for false, then you can't do math
on the result because it isn't a number. I think this has come up before in
the discussion.

--Sam

Re: What about the name of the second prerequisite?

[Sam Kendall]

Can be done with functions, e.g., the second prereq is $(word 2,$+). Given
that it’s straightforward composition of documented features, you’d want to
document it only if it were very commonly needed. Which it isn’t. That’s my
two cents, anyway.

Sam

On Fri, Jun 14, 2019 at 11:29 PM Dan Jacobson  wrote:

> (info "(make) Automatic Variables") has
>
> '$<' The name of the first prerequisite...
> '$?' The names of all the prerequisites that are newer than the target...
> '$^' The names of all the prerequisites, with spaces between them...
> '$+' This is like '$^', but prerequisites listed more than once are...
> '$|' The names of all the order-only prerequisites...
>
> OK, OK, OK, OK, OK!
>
> But it really should also mention the official recommended way to (drum
> roll)...
>
> Get the name of the second prerequisite.
>
> OK, the first born son inherits the throne. But at least document the
> workaround for accessing the second born son. Thanks. P.S., third born
> too. And how about last born also.
>
> I'm not asking for code changes, just officially documenting the proper
> way to access them.
>
> ___
> Bug-make mailing list
> Bug-make@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-make
>
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: addsuffix influence...

[Sam Kendall]

On Thu, Mar 28, 2019 at 9:24 PM 積丹尼 Dan Jacobson 
wrote:

> I thought targets
> A:$D/$(addsuffix .kmz, $L $N)
> B:$D/$L.kmz $D/$N.kmz
> should do the same.


 No. If   D=X_X_X_X,  L=light, and N=noise, then

A:$D/$(addsuffix .kmz, $L $N)
B:$D/$L.kmz $D/$N.kmz

expands to

A: X_X_X_X/light.kmz noise.kmz
B: X_X_X_X/light.kmz X_X_X_X/noise.kmz

You're already off the rails, so I haven't tried to understand the rest of
your email. If you're going to post to many people what you think is a bug,
please cut your example down to the smallest, simplest thing that
demonstrates the bug.

--
Sam Kendall


>
$ cat makefile
> D=X_X_X_X
> N=noise
> L=light
> A:$D/$(addsuffix .kmz, $L $N)
> B:$D/$L.kmz $D/$N.kmz
> %.kmz:%.kml; minizip -o $@ $?
> %.kml:%.kml0; fgrep -v '?xml' $? > $@
> %.kml0: n input.txt; mode=$* ./n input.txt > $@
> $D/%:%; cp -a $? $@
> $ touch n input.txt; for i in A B; do make -n $i > $i; done
> $ diff A B
> 7a8
> > cp -a noise.kmz X_X_X_X/noise.kmz
>
> And here we see even the presence of addsuffix on a non-relevant line
> influences other lines.
>
> $ cat makefile |sed /A/s/add/xxx/| make -f - -n B|sed $\!d
> rm noise.kml noise.kmz noise.kml0 light.kml light.kmz light.kml0
> $ cat makefile |   make -f - -n B|sed $\!d
> rm noise.kml noise.kml0 light.kml light.kmz light.kml0
>
> GNU Make 4.2.1
>
> ___
> Bug-make mailing list
> Bug-make@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-make
>
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #54630] "obsolete" language too strong

[Sam Kendall]

Follow-up Comment #1, bug #54630 (project make):

Another example is the advice not to omit parens in references to
single-character variables: "you could reference the variable x with ‘$x’.
However, this practice is strongly discouraged, except in the case of the
automatic variables..." I've found that in the bodies of user-defined
functions, particularly those already laden with parentheses, '$1' is
significantly more readable than '$(1)'. Suggested tweak: "the usual style is
to include the parentheses except in the case of automatic variables..."
Unless there's some reason other than style preference, in which case that
reason should be spelled out.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make