[bug #52209] Support for ifeq function

[Rob]

Follow-up Comment #4, bug #52209 (project make):

Patch added.

The rational is that this is an operation needed to support rebuilding of
targets when recipes change.

Support for rebuilding of targets on recipe change requires the recipe of
every target to be expanded and compared with its previously used recipe.
These happens on every build, even if all targets are up-to-date, so can
contribute a significant amount to the processing time of a large mostly
up-to-date project. A more efficient way to compare previous and current
recipes than that in the first post would help reduce processing time.

I have only created the $(ifeq ...) function and added nothing to .FEATURES,
or test suite, or documentation. I can do this if the patch is accepted.


(file #42159)
___

Additional Item Attachment:

File name: function.c.patch   Size:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

[bug #64822] Fix appending to a pattern specific variable.

[Rob]

Follow-up Comment #2, bug#64822 (group make):

Sorry I'm not in a position to confirm it myself, but it looks like this could
also fix bug #36486.


___

Reply to this item at:

  

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

Re: New Feature Submission for GNU Make

[Rob Walker]

Have you considered the backwards compatibility issues this patch might
cause?

The functions you've implemented for inclusion are implementable
directly in the make language.  Therefore, there are very likely
implementations floating around in existing makefiles, very likely with
the names you've chosen, but possibly with slightly different semantics.

When both make and a makefile define a function $(call fn) always
resolves to the built-in.

Until make gives make programmers more control over their environment, I
think a moratorium on new built-in functions might be a good idea.  Any
seconds?

-Rob


On 6/12/11 2:42 PM, Ben Robinson wrote:
> Hello,
> 
> I thank the community for their feedback regarding my submission of
> $(trimpath ...) and $(relpath ...).  Many other benefits to the
> submission have been identified which would improve GNU Make if
> incorporated.  However, I see two outstanding issues which remain:
> 
> 1) The submission needs to be refactored to incorporate the coding style
> and macros of 3.82 (it is currently based on 3.81).  I will proceed with
> this effort as soon as I hear word that the submission is approved.
> 
> 2) Handling of symbolic links.  The current implementation only analyzes
> the string representation of the path, and does not touch the file
> system.  This has the advantage of performance, and the fact that
> expanding and resolving symbolic links can lead to longer resultant
> paths, when the purpose of the symbolic link was to skip over numerous
> long directory names.  I would recommend the submission remain in its
> current form, and if symbolic link expansion is needed, it be added to
> another new function, such as $(resolve-symlinks...), as was previously
> suggested.  In this way, the expansion of symbolic links can be
> controlled by the user, when the user desires that functionality.
> 
> I appreciate the community's feedback, and I look forward to hearing
> approval for submission if appropriate.
> 
> Thank you,
> 
> Ben Robinson
> 
> 
> 
> On Tue, May 31, 2011 at 9:37 AM, Howard Chu  <mailto:h...@highlandsun.com>> wrote:
> 
> Edward Welbourne wrote:
> 
> Pretty weak. If a few more include paths were added to the
> project it would
> still break, regardless of your patch.
> 
> 
> When you have thousands of object files, shortening the name of each
> by several bytes when invoking ar can make room for really quite
> a lot
> more files before you run up against the command-line length limit.
> 
> Never understimate the value of a modest shortening of file names -
> when our ar command-line got to about 230 kibibytes, we had to
> re-work
> the way we invoked ar !
> 
> 
> Whatever you're doing, you're doing it wrong. ;)
> 
> If you're tossing a bunch of object files into an ar library simply
> for grouping purposes, and all of the object files will eventually
> be used in the final executable, it's faster to use ld -r and
> combine groups of them all into a single object file. If you
> profiled your build I'm sure you would find that a large percentage
> of time is being wasted in ar itself.
> 
> And if you're really running a build with thousands of object files,
> on a frequent basis, you're foolish not to profile it and figure out
> what else you're doing wrong. Giant monolithic command lines also
> prevent you from leveraging parallel make, so that's another reason
> not to do things that way...
> 
> 
> -- 
>  -- Howard Chu
>  CTO, Symas Corp.   http://www.symas.com
>  Director, Highland Sun http://highlandsun.com/hyc/
>  Chief Architect, OpenLDAP  http://www.openldap.org/project/
> 
> 
> 
> 
> ___
> 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

Potential

[Rob Holbert]

Hello,

I ran across perhaps a bug or need for another feature at least. If a list
of items has words beginning with both upper and lower case letters, the
resulting $(sort $(LIST)) will result in all capital letter words coming
before the lower case words. In this case, Zebra.c would appear before
apple.c. This is dictated by the ASCII chart of course. However, it is not
lexical order as the manual explains the function is. Lexical would be
apple.c Zebra.c.

This is solved easily by making the sort comparison convert all alphas to
lower case before comparing, leaving the original string case unchanged.

I like to use sort to put my sources in order. This way it is easier to see
if an object file is missing for instance.

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

Follow-up

[Rob Holbert]

Wanted to followup to my earlier email. Attached is the smallest makefile I
could create to demonsterate the issue.

or

#does not sort lexically like expected
LIST = $(sort widget.c main.c ad.c Buzzer.c)
#target
all: list
list:
@echo $(LIST)
.PHONY: all list

Previous email:
Hello,

I ran across perhaps a bug or need for another feature at least. If a list
of items has words beginning with both upper and lower case letters, the
resulting $(sort $(LIST)) will result in all capital letter words coming
before the lower case words. In this case, Zebra.c would appear before
apple.c. This is dictated by the ASCII chart of course. However, it is not
lexical order as the manual explains the function is. Lexical would be
apple.c Zebra.c.

This is solved easily by making the sort comparison convert all alphas to
lower case before comparing, leaving the original string case unchanged.

I like to use sort to put my sources in order. This way it is easier to see
if an object file is missing for instance.

Best Regards,
Rob


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

Re: make buildin function strings handling

[Rob Walker]

That's the expected behavior...

Your code below is equivalent to:

tmp1=$(obj)
tmp2=$(word 1,$(obj))

Try it yourself:

makefile:

all: ; @#
$(info $(word 1,$$(foo))

-Rob

On 5/21/2012 9:24 AM, Incarnation Lee wrote:
I am improving my codes which managed by gnu make recently. And I 
found a behavior of make buildin function when handling strings. I 
assume that this maybe for some specific situations. My OS is Ubuntu 
12.04 and with gnu make v.3.81. Details list follow:

obj=a.o b.o c.o

define Test
tmp1=$(word 1, $$(obj))
endef
$(eval $(call Test))
tmp2=$(word 1,$(obj))

echo $(tmp1)
echo $(tmp2)

do make -n
and get the result
a.o b.o c.o(tmp1)
a.o(tmp2)


___
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: [bug #36641] Crash when using ridiculously large target names

[Rob Walker]

On 6/12/12 10:16 AM, anonymous wrote:
> URL:
>   <http://savannah.gnu.org/bugs/?36641>
>
>  Summary: Crash when using ridiculously large target names
>  Project: make
> Submitted by: None
> Submitted on: Tue 12 Jun 2012 05:16:49 PM UTC
> Severity: 3 - Normal
>   Item Group: Bug
>   Status: None
>  Privacy: Public
>  Assigned to: None
>  Open/Closed: Open
>  Discussion Lock: Any
>Component Version: 3.82
> Operating System: Any
>Fixed Release: None
>Triage Status: None
>
> ___
>
> Details:
>
> If the stem len is bigger than PATH_MAX, it results in a buffer over run:
>
> 455a456
>> unsigned int stemlen_copy;
> 494,495c495,497
> <   strncpy (stem_str, stem, stemlen);
> <   stem_str[stemlen] = '\0';
> ---
>>   stemlen_copy = stemlen > sizeof(stem_str) ? sizeof(stem_str) :
> stemlen;
>>   strncpy (stem_str, stem, stemlen_copy);
>>   stem_str[stemlen_copy] = '\0';

The proposed patch has yet another buffer overrun, off by one.

-Rob


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

error reporting

[Rob Juergens]

Given the make file (makefile):

--
foo : bar
--

gmake 3.75 gives this:

gmake: *** No rule to make target 'bar', needed by 'foo'. Stop.

gmake 4.0 gives this:

gmake: ***. stop.

This has caused a lot of time trying to figure out what is wrong with the 
makefile. A big step backward in error reporting.
Please fix this.

Also, attached are VS2008 & VS2012 solution/project files. No one is using 
VS2003 anymore.

Thanks,
Rob Juergens
rjuerg...@esri.com<mailto:rjuerg...@esri.com>








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

RE: error reporting

[Rob Juergens]

You are correct in that building make-4.0 on solaris does not show that 
problem. However building with VS2013 does not fix it.
Attached are 2013 files and updated other files

-Original Message-
From: Paul Smith [mailto:psm...@gnu.org] 
Sent: Tuesday, April 08, 2014 5:07 AM
To: Philip Guenther
Cc: Rob Juergens; bug-make@gnu.org
Subject: Re: error reporting

On Mon, 2014-04-07 at 21:26 -0700, Philip Guenther wrote:
> I am unable to reproduce this:

Based on the offer of MSVC project files I would guess Rob is running on 
Windows.

I expect this is a result of the buggy snprintf()/vsnprintf() implementations 
in the Windows MSVC compiler (well, by "buggy" I mean not conforming to the ISO 
C99 standard, which is 15 years old now...)

I actually think that MSVC 2013 is supposed to fix this, because the
C++11 standard has moved up to incorporate a number of the C99 features
(C++03 only relied on C89) which is forcing Microsoft to finally implement them.

As John mentions, I rewrote all that code since the 4.0 release to rely only on 
features available in the C89 standard, which likely fixes this issue as well.




make_msvc_net2008.sln
Description: make_msvc_net2008.sln


make_msvc_net2008.vcproj
Description: make_msvc_net2008.vcproj


make_msvc_net2012.sln
Description: make_msvc_net2012.sln


make_msvc_net2012.vcxproj
Description: make_msvc_net2012.vcxproj


make_msvc_net2013.sln
Description: make_msvc_net2013.sln


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

RE: error reporting

[Rob Juergens]

Note that in Unix, vsnprintf() returns the TOTAL number of chars needed (add 1 
for the null). If the output would overflow the buffer, then you would get a 
return value larger than the specified buffer size.

In Windoze,  vsnprintf() will return -1 if the buffer would be overflowed, and 
there is no indication of what length the buffer must be.

In either case, the buffer will be filled up to the end, but with no 
terminating null.

Microsoft is *not* going to change this, since that would break who-knows how 
many existing programs that depend on that behavior.

-Original Message-
From: Paul Smith [mailto:psm...@gnu.org] 
Sent: Tuesday, April 08, 2014 5:07 AM
To: Philip Guenther
Cc: Rob Juergens; bug-make@gnu.org
Subject: Re: error reporting

On Mon, 2014-04-07 at 21:26 -0700, Philip Guenther wrote:
> I am unable to reproduce this:

Based on the offer of MSVC project files I would guess Rob is running on 
Windows.

I expect this is a result of the buggy snprintf()/vsnprintf() implementations 
in the Windows MSVC compiler (well, by "buggy" I mean not conforming to the ISO 
C99 standard, which is 15 years old now...)

I actually think that MSVC 2013 is supposed to fix this, because the
C++11 standard has moved up to incorporate a number of the C99 features
(C++03 only relied on C89) which is forcing Microsoft to finally implement them.

As John mentions, I rewrote all that code since the 4.0 release to rely only on 
features available in the C89 standard, which likely fixes this issue as well.


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

RE: error reporting

[Rob Juergens]

Attached is a rewrite of the method vfmtconcat() in output.c. It seems to fix 
the problem.

-Original Message-
From: Paul Smith [mailto:psm...@gnu.org] 
Sent: Tuesday, April 08, 2014 2:00 PM
To: Rob Juergens
Cc: Philip Guenther; bug-make@gnu.org
Subject: Re: error reporting

On Tue, 2014-04-08 at 20:15 +, Rob Juergens wrote:
> Note that in Unix, vsnprintf() returns the TOTAL number of chars 
> needed (add 1 for the null). If the output would overflow the buffer, 
> then you would get a return value larger than the specified buffer 
> size.
> 
> In Windoze,  vsnprintf() will return -1 if the buffer would be 
> overflowed, and there is no indication of what length the buffer must 
> be.

Yes, I'm well aware of the difference in behavior, unfortunately :-/.

> Microsoft is *not* going to change this, since that would break 
> who-knows how many existing programs that depend on that behavior.

Well, that's a shame: if true MSVC will never be a conforming compiler 
implementation for C++11 or any newer C++ standard.

The C++11 standard clearly states that the return value of the
(standard) vsnprintf() function must be the "number of characters that would 
have been written if [the buffer size] had been sufficiently large, not 
counting the terminating null character".  This is basically the exact text for 
the C99 standard, imported into the C++11 standard.

Microsoft is on the C++ standards committee and they certainly were aware of 
this, so my hope is they have a plan to allow for both "legacy"
implementations and "conforming" implementations.

> Attached are 2013 files and updated other files

I'm really not excited about the prospect of continuing to add new project 
files every year for each new version of Visual Studio.  Isn't there any sort 
of backward-compatibility that allows the older files to work in newer Visual 
Studio releases?

Also, is there any way to get these project files out of the root directory?  
I'd be a lot more sanguine about them if we could put them into the "w32" 
subdirectory, or in an "msvc" subdirectory or something and get them out of the 
way.

To my mind the only reason to ship Visual Studio project files with GNU make is 
if there are people who want to develop and enhance GNU make itself, and who 
want to use Visual Studio to do it.  For people who just want to build GNU make 
on Windows and use the result for other projects, surely it's easier to just 
run a .bat build file or maybe use an nmake file to build make.exe; that's all 
you need.  Visual Studio seems like real overkill for that.


/* Output to stdout / stderr for GNU make
Copyright (C) 2013 Free Software Foundation, Inc.
This file is part of GNU Make.

GNU Make is free software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation; either version 3 of the License, or (at your option) any later
version.

GNU Make is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE.  See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with
this program.  If not, see <http://www.gnu.org/licenses/>.  */

#include "makeint.h"
#include "job.h"

/* GNU make no longer supports pre-ANSI89 environments.  */

#include 
#include 
#include 

#ifdef HAVE_UNISTD_H
# include 
#endif

#ifdef HAVE_FCNTL_H
# include 
#else
# include 
#endif

#ifdef WINDOWS32
# include 
# include 
# include "sub_proc.h"
#endif /* WINDOWS32 */

struct output *output_context = NULL;
unsigned int stdio_traced = 0;

#define OUTPUT_NONE (-1)

#define OUTPUT_ISSET(_out) ((_out)->out >= 0 || (_out)->err >= 0)

#ifdef HAVE_FCNTL
# define STREAM_OK(_s)((fcntl (fileno (_s), F_GETFD) != -1) || (errno != 
EBADF))
#else
# define STREAM_OK(_s)1
#endif

/* I really want to move to gnulib.  However, this is a big undertaking
   especially for non-UNIX platforms: how to get bootstrapping to work, etc.
   I don't want to take the time to do it right now.  Use a hack to get a
   useful version of vsnprintf() for Windows.  */
#ifdef __VMS
# define va_copy(_d, _s) ((_d) = (_s))
#endif
#ifdef _MSC_VER
# define va_copy(_d, _s) ((_d) = (_s))
# define snprintf msc_vsnprintf
static int
msc_vsnprintf (char *str, size_t size, const char *format, va_list ap)
{
  int len = -1;

  if (size > 0)
len = _vsnprintf_s (str, size, _TRUNCATE, format, ap);
  if (len == -1)
len = _vscprintf (format, ap);

  return len;
}
#endif

/* Write a string to the current STDOUT or STDERR.  */
static void
_outputs (struct output *out, int is_err, const char *msg)
{
  if (! out || ! out->syncout)
{
  FILE *f = is_err ? stderr : stdout;

filedef.h comment about file_timestamp_sprintf of by 10

[Rob Franken]

Dear Make maintainers,

While debugging some superfluous rebuilds in a project I wanted to
quickly hack in some printing of file_timestamps on out of date files.
When doing that I found the usefull helperfunction
file_timestamp_sprintf and since I knew that in the project I was
working on that before -999 or after  wouldn't be a real problem I
just used the 19 that was mentioned in the comment. While that is
perhaps not the best idea to do I later found out that this 19 was of
by 10 since the nanoseconds were added. (Also my gut feeling to add 1
just in case the \0 end byte wasn't included was correct, but that might
just be a matter of personal preference, and not a bug.)

Kind Regards, 

=== snip: filedef.h:145 ===
/* Upper bound on length of string "-MM-DD HH:MM:SS.N"
   representing a file timestamp.  The upper bound is not necessarily 19,
   since the year might be less than -999 or greater than .

=== snip ===

-- 
Rob

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

Re: Need help with Windows port for GNU make (+ DOS pretesters)

[Rob Tulloh]

Paul,

Thanks for your comments. I believe that
someone could devote more time than I have and do
a lot of good things to improve the WIN32 story for GNU make.
I have certainly enjoyed working on the tool. I hope
someone else will seize the challenge. I am glad to
facilitate the transition as well. Please don't hesitate to
contact me if you would like to talk about it or
gain historical knowledge. I am happy to do this.

Rob

- Original Message -
From: Paul D. Smith <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; Automake List
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, May 09, 2000 4:18 PM
Subject: Need help with Windows port for GNU make (+ DOS pretesters)


> Hi all.
>
> Recently Rob Tulloh has notified me that he's no longer able to give the
> maintenance of the Windows port of GNU make the attention he would like,
> due to other demands on his time.  I would like to publicly thank him
> for his many years of dedication to and support of that effort, and I
> hope his workload eases in the future so he can spare us some more
> cycles! :)
>
> This leaves us without anyone (AFAIK) on the alpha-test or pre-test
> lists who is actively supporting or testing the Windows ports.
> Unfortunately (? ;), I don't have a Windows system that I can even test
> the build on, much less the expertise to provide code fixes.  Indeed, we
> had some issues with the current 3.79 release on Windows :(.
>
> So, if you are interested in helping pretest GNU make on Windows, and/or
> if you are willing and able to help answer Windows-specific problems (a
> good number of problems I see are related to Windows shells, etc. and I
> just don't understand the issues well enough to provide solutions),
> and/or if you would like to consider Windows-specific enhancements,
> please let me know.
>
> Thanks in advance.
>
> BTW, while Eli Zaretskii is still providing excellent support for the
> DOS port of GNU make, it would be great if we had a few more pretesters
> for this port, as well.  Let me know if you'd like to become a pretester
> for GNU make.
>
> --
> --
-
>  Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
>  http://www.gnu.org
http://www.ultranet.com/~pauld/gmake/
>  "Please remain calm...I may be mad, but I am a professional." --Mad
Scientist
>

Re: svn 14407 broke the repository.

[Rob Landley]

On Friday 03 March 2006 11:39 am, Bernhard Fischer wrote:
> >When the path the file is actually at would
> >be /root/busybox/coreutils/libcoreutils/Makefile.in
>
> Looks like doesn't understand the $(notdir) there.
> Can you please try to just drop that whole line? This would not
> initialize the WHATEVER-y:= lists and may barf if we didn't initialize
> them but just say WHATEVER-y+=whatever.c

Interesting.

The line numbering is off.  Although it _says_ it's complaining about line 
247, it's actually complaining about line 249, which is:

include $(patsubst %,%/Makefile.in,$(SRC_DIRS))

If I comment that out, it then says "No rule to make target 
`/root/scripts/config/Makefile', needed by `scripts/config/Makefile'.

P.S.  Either way it still tries to run the "h;y/[a-z]/[A-Z]/" thing 
through /bin/sh instead of sed.  This doesn't appear to be a sed problem, but 
a make problem.

> >Rob
> >
> >(Oh, and make distclean isn't zapping libbusybox.*)
>
> You'd have to have CONFIG_BUILD_LIBBUSYBOX (or however it's called) set.
> Perhaps we should just blindly rm -f libbusybox.* ?

Probably a good idea.  It's reasonable for "make clean" to depend on 
your .config to work right, but make distclean shouldn't.

Rob
-- 
Never bet against the cheap plastic solution.


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

Re: svn 14407 broke the repository.

[Rob Landley]

On Thursday 02 March 2006 3:51 pm, Bernhard Fischer wrote:
> On Thu, Mar 02, 2006 at 02:32:53PM -0500, Rob Landley wrote:
> >On Thursday 02 March 2006 1:18 pm, Bernhard Fischer wrote:
> >> >Not happy...
> >>
> >> Missing dependency of applets/applets.o vs. .config.
> >> Fixed in r14431.
> >
> >Yup, that's fixed.  Thanks. :)
> >
> >It now builds for me if I disable everything in the e2fsprogs directory,
> > which is cool.  Unfortunately, if I switch on e2fsprogs:
> >
> >make: *** No rule to make target
> >`/home/landley/busybox/busybox/e2fsprogs/blkid_getsize.c', needed by
> >`/home/landley/busybox/busybox/e2fsprogs/blkid/blkid_getsize.o'.  Stop.
> >
> >This is under ubuntu.
>
> my incarnation of debian (also a dedicated ubuntu box) has make-3.81b4.
> I'm curiuos as to what make version is driving at your end?

The fall 2005 release has make 3.80 (same as Red Hat 9).

> I *think* that i'm tripping a bug in "my" make-3.81b4 version.
> Please reread the bug with-make-and-e2fsprogs mail ¹) or just apply
> *and* *checkin* the attached alleged proper fix which will make
> make-3.81b4 (from debian) go up in flames but will work four your
> make-3.80...
>
> ¹) http://busybox.net/lists/busybox/2006-March/018910.html

Huh.  For some reason I don't seem to have gotten a copy of that message.  
Weird.

This patch does indeed fix it for me on ubuntu.

Red Hat 9 still barfs on the line 247 of Makefile:
$(foreach d,$(DIRS_UPPER),$(eval $(notdir $(d))-y:=))

The error messages are things like:
Makefile:247: /root/coreutils/libcoreutils/Makefile.in: No such file or 
directory

When the path the file is actually at would 
be /root/busybox/coreutils/libcoreutils/Makefile.in

Rob

(Oh, and make distclean isn't zapping libbusybox.*)
-- 
Never bet against the cheap plastic solution.


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

Optimization for $(if ...) function

[Rob W]

The $(if ...) function uses strlen to decide if the expanded condition is
true. But it only needs to know if the string is not empty, and not the
length of the string.

I think it only needs to test if the first character is not nul. This is
the change:

1248c1248
<   result = strlen (expansion);
---
>   result = (*expansion != '\0');

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