[bug #44742] Double-dep with double-colon rule not built

2015-04-05 Thread Ed 
URL:
  

 Summary: Double-dep with double-colon rule not built
 Project: make
Submitted by: mohawk
Submitted on: Mon 06 Apr 2015 00:08:02 GMT
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.1
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

If you do "make -j4 linkext", it will not link the *.so. If you do "make -j4
dynamic", or "make -j1 linkext", it will.

This is the whole of the "linkext" rule:

linkext :: dynamic
$(NOECHO) $(NOOP)


I attach the fuller log, the (cut-down) Makefile, the "remake -x" output of
each case.

Full repro by: cpanm --dev --look PDL; cd Basic/Core; make linkext

Log:

$ make -v
GNU Make 4.1
[...]
$ remake -v
GNU Make 4.1+dbg0.91
[...]
$ rm -rf ../../blib ; make clean >/dev/null; mv Makefile.old Makefile ; cp
Version.pm.KEPT Version.pm ; cp Types.pm.KEPT Types.pm ; remake -x linkext
>output.linkext ; l ../../blib/arch/auto/PDL/Core/Core.so
Using new 64bit index support
Using new 64bit index support
ls: cannot access ../../blib/arch/auto/PDL/Core/Core.so: No such file or
directory
$ rm -rf ../../blib ; make clean >/dev/null; mv Makefile.old Makefile ; cp
Version.pm.KEPT Version.pm ; cp Types.pm.KEPT Types.pm ; remake -x dynamic
>output.dynamic ; l ../../blib/arch/auto/PDL/Core/Core.so
Using new 64bit index support
Using new 64bit index support
-rwxr-xr-x. 1 user user 168335 Apr  6 00:42
../../blib/arch/auto/PDL/Core/Core.so




___

File Attachments:


---
Date: Mon 06 Apr 2015 00:08:02 GMT  Name: log.txt  Size: 1kB   By: mohawk


---
Date: Mon 06 Apr 2015 00:08:02 GMT  Name: output.dynamic  Size: 24kB   By:
mohawk


---
Date: Mon 06 Apr 2015 00:08:02 GMT  Name: Makefile  Size: 11kB   By: mohawk


---
Date: Mon 06 Apr 2015 00:08:02 GMT  Name: output.linkext  Size: 21kB   By:
mohawk



___

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 #44742] Double-dep with double-colon rule not built

2015-08-02 Thread Ed 
Follow-up Comment #2, bug #44742 (project make):

Thanks for taking a look! I tried patching my local GNU make 4.1 per your
suggestion, and it hasn't helped. Here is a fuller set of steps to repro:


# initial setup
cpanm --dev --look PDL
cpanm ExtUtils::MakeMaker@7.05_19 # 7.05* has double-level
perl Makefile.PL
cd Basic/Core

# first time, and show failure with -j4 linkext
make -j4 linkext 
ls ../../blib/arch/auto/PDL/Core/Core.so # not found

# keep old files to save time
cp Version.pm Version.pm.KEPT ; cp Types.pm Types.pm.KEPT

# show works with -j4 dynamic
rm -rf ../../blib ; make clean >/dev/null; mv Makefile.old Makefile ; cp
Version.pm.KEPT Version.pm ; cp Types.pm.KEPT Types.pm ; make -j4 dynamic ; ls
../../blib/arch/auto/PDL/Core/Core.so 

# show works with -j1 linkext
rm -rf ../../blib ; make clean >/dev/null; mv Makefile.old Makefile ; cp
Version.pm.KEPT Version.pm ; cp Types.pm.KEPT Types.pm ; make -j1 linkext; ls
../../blib/arch/auto/PDL/Core/Core.so

# show fails again/still with -j4 linkext
rm -rf ../../blib ; make clean >/dev/null; mv Makefile.old Makefile ; cp
Version.pm.KEPT Version.pm ; cp Types.pm.KEPT Types.pm ; make -j4 linkext; ls
../../blib/arch/auto/PDL/Core/Core.so


This is a problem for EUMM since it's a bug that affects already-existing GNU
make, so I'm going to have to find a way to make this not happen for current
GNU make. However, it also seems like it would be worth finding and fixing
this.

___

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 #44742] Double-dep with double-colon rule not built

2015-08-02 Thread Ed 
Follow-up Comment #3, bug #44742 (project make):

Thanks for taking a look! I tried patching my local GNU make 4.1 per your
suggestion, and it hasn't helped. Here is a fuller set of steps to repro:


# initial setup
cpanm --dev --look PDL
cpanm ExtUtils::MakeMaker@7.05_19 # 7.05* has double-level
perl Makefile.PL
cd Basic/Core

# first time, and show failure with -j4 linkext
make -j4 linkext 
ls ../../blib/arch/auto/PDL/Core/Core.so # not found

# keep old files to save time
cp Version.pm Version.pm.KEPT ; cp Types.pm Types.pm.KEPT

# show works with -j4 dynamic
rm -rf ../../blib ; make clean >/dev/null; mv Makefile.old Makefile ; cp
Version.pm.KEPT Version.pm ; cp Types.pm.KEPT Types.pm ; make -j4 dynamic ; ls
../../blib/arch/auto/PDL/Core/Core.so 

# show works with -j1 linkext
rm -rf ../../blib ; make clean >/dev/null; mv Makefile.old Makefile ; cp
Version.pm.KEPT Version.pm ; cp Types.pm.KEPT Types.pm ; make -j1 linkext; ls
../../blib/arch/auto/PDL/Core/Core.so

# show fails again/still with -j4 linkext
rm -rf ../../blib ; make clean >/dev/null; mv Makefile.old Makefile ; cp
Version.pm.KEPT Version.pm ; cp Types.pm.KEPT Types.pm ; make -j4 linkext; ls
../../blib/arch/auto/PDL/Core/Core.so


This is a problem for EUMM since it's a bug that affects already-existing GNU
make, so I'm going to have to find a way to make this not happen for current
GNU make. However, it also seems like it would be worth finding and fixing
this.

(file #34568)
___

Additional Item Attachment:

File name: Makefile.works Size:29 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 #44742] Double-dep with double-colon rule not built

2015-08-09 Thread Ed 
Follow-up Comment #5, bug #44742 (project make):

It definitely *does* ruin the build. My question is, is this by design or
simply a long-standing bug in GNU make? It doesn't happen on BSD make, for
instance.

___

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 #30914] Standard library search path not configurable

2010-08-30 Thread Ed Martin 

URL:
  

 Summary: Standard library search path not configurable
 Project: make
Submitted by: edman007
Submitted on: Tue 31 Aug 2010 03:36:36 AM GMT
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: CVS
Operating System: Any
   Fixed Release: None
   Triage Status: None

___

Details:

for rules like this:

foo: -lbar

According to the docs:

> When a prerequisite's name has the form ‘-lname’, make handles it
specially by searching for the file libname.so, and, if it is not found, for
the file libname.a in the current directory, in directories specified by
matching vpath search paths and the VPATH search path, and then in the
directories /lib, /usr/lib, and prefix/lib (normally /usr/local/lib, but
MS-DOS/MS-Windows versions of make behave as if prefix is defined to be the
root of the DJGPP installation tree). 

So, /lib, /usr/lib and $libdir (from the configure script) get compiled in as
part of the search path. However many distros use lib64 and thus the search
path should be /lib64 and /usr/lib64 ($libdir is confirgurable, so I don't
that that matters much). But from what I can tell there is no way, short of
patching, to remove /lib and /usr/lib from that search path (causes problems,
say building a 64-bit app with a 32-bit version available, unlike gcc, make
wouldn't just skip over it because it is the wrong arch). And more importantly
there is no way to add multiple directories to this path, thus you can't put
/lib64, /usr/lib64 and /usr/local/lib64 in the search path (or even
/usr/local/lib if make was installed into /usr [unless you explictly set
$libdir to /usr/local/lib, which goes against what the configure script says
that directory is used for]).

Make should not use the --libdir config argument to set this path (it goes
against what the config docs say '--libdir=DIR object code libraries
[EPREFIX/lib]'). A better solution might be if the configure script offered a
method to set the path outright (such as
--standard-path=/lib64:/usr/lib64:/usr/local/lib64 ) and this could then
default to something reasonable, possibly including the common lib64 variant
when when it exists on an x86_64 build.




___

Reply to this item at:

  

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


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

include should be relative to current Makefile

2012-05-12 Thread Ed H 
I've been trying to put together a non-recursive build system and ran into
the fact that gmake's "include" directive is always relative to the CWD.
This isn't how cpp does things, and is unexpected behavior to say the least.

Is there some unavoidable reason why relative includes aren't relative to
the including Makefile (and not the original make invocation's CWD)?

Here's a simple example:

top/Makefile:
> test:
> @echo $(MAKEFILE_LIST)
top/a/Makefile:
> include ../Makefile
top/a/b/Makefile:
> include ../Makefile
Doing "make test" in top/a/b will fail because top/a/Makefile recursively 
includes
itself instead of including top/Makefile. Compare with cpp:

top/t.c:
> #include 
> int main( int argc, char *argv[] ) { printf( "Works!\n" ); return 0; }
top/a/t.c:
> #include "../t.c"
top/a/b/t.c: 
> #include "../t.c"


gcc -o t t.c from top/a/b works as expected.


I think changing gmake's behavior to match cpp's will eliminate the need for a 
lot
of hacky farting around to get non-recursive systems working smoothly. An 
important
design consideration is keeping the complexity out of the leaf Makefiles so it 
would
be nice not to have to have boiler plate lines like:

include $(addprefix ../,$(lastword $(MAKEFILE_LIST)))


It would also eliminate the need for new built-in variables
(see http://savannah.gnu.org/bugs/?35485)

Are we locked into a bad design decision at this point, or can this be fixed?


I should note that I've built a lot of recursive build systems (including very 
large
and complicated ones for million+ line projects) and I've always assumed the 
include
directive worked the way I expected, so I don't see offhand what would break
for recursive builds. Non-recursive builds would probably welcome the chance
to make things simpler (and they seem to be rarer than recursive builds still).
A possible solution might be to do the expected thing by default and fall back 
to
CWD-relative includes if the Makefile-relative target doesn't exist? Adding a
command-line option isn't great (users should just be able to type "make" and
have it work).


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

Re: include should be relative to current Makefile

2012-05-15 Thread Ed H 





>
>By the same logic, one can use a (module-specific) variable meaning
>"here" in each sub-directory's make-file fragments; so foo/config.mk
>refers to its source files as $(FOOSRC)/bar.c and so on, rather than
>assuming FOOSRC=. (although that likely remains the ?= setting in
>foo/Makefile, for use when building just foo).  You can then equally
>include $(FOOSRC)/baz/config.mk as long as you first set BAZSRC to
>$(FOOSRC)/baz so that it knows where *its* "here" is, and so on.  (Of
>course, if you have two copies of baz in use by different contexts, it's
>going to get weirder; but that was going to be a problem any way you
>like to come at it.)  For out-of-source building, you also need parallel
>FOOOUT and BAZOUT variables, of course.  Note that you need these
>variables to get the commands and rules right, so I don't really see a
>strong case for getting rid of the need for them when including
>makefiles.
>
>So, while the include structure in make files is a pain to re-work
>during converting from recursive make, it's really just another example
>of how you have to re-work the rest of the make-file's content; so I'm
>not persuaded that the (tempting) case for making the inclusion easier
>is actually compelling.  It wouldn't solve the matching problems for
>source lists and command-lines, after all.
>
>       Eddy.
>
Thanks for the reply. I should point out I'm talking specifically about how
include works, not how the rest of the rule processing etc. works. I'd
suggest that the compelling argument for change is that leaf Makefiles are
the things people of various skill levels on the team actually interact with,
and assuming include worked the way I had expected it to work they could
remain fairly vanilla. E.g.:


ifndef TOP

include ../Makefile

else

SUBDIRS = 
TARGETS = 
SRCS = 

endif

All of the complexity you allude to can be safely buried in the TOP-level
Makefiles, leaving most users blissfully unaware of how the sausage is made. 
Another idea I had for a solution is to add yet another directive, possibly
something like:


.include ../Makefile

(dot-include is a mnemonic for "include relative to here"). 

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

Re: include should be relative to current Makefile

2012-05-16 Thread Ed H 



>
> From: Edward Welbourne 
>To: Ed H  
>Cc: bug-make@gnu.org 
>Sent: Wednesday, May 16, 2012 1:21 AM
>Subject: Re: include should be relative to current Makefile
> 
>> ifndef TOP
>>
>> include ../Makefile
>>
>> else
>>
>> SUBDIRS = 
>> TARGETS = 
>> SRCS = 
>>
>> endif
>>
>> All of the complexity you allude to can be safely buried in the TOP-level
>> Makefiles,
>
>I can't help but think this is an entirely upside-down approach.  You
>appear to be expecting context's make-file to supply values for the SRCS
>and SUBDIRS of the module, which should surely be the master source for
>that information.  When sub-module foo is under separate version control
>from the rest, this is particularly important: the source list may
>change from one release of foo to the next - the parent shouldn't need
>to care - that's *why* it includes a make fragment from the sub-module.
>

I should have been more clear,  I'm setting up the build so each user-specified
module Makefile (which lives in the same directory as the source for that 
module)
includes the parent's Makefile, specifies things to be built in that directory 
and
also specifies any sub-directories (which have their own Makefiles). Somewhere
at the TOP is the main project Makefile which includes a bunch of stuff for all
the rules and build options etc. This top-level Makefile also includes 
everything
going back down the tree following all of the module SUBDIRS, which are now
getting their TARGETS/SRCS etc. added into the dependency graph. My goal is
to have a single Makefile in each build directory which (as simply as possible)
specifies the what and not the how of building everything. "make" in any
sub-directory should behave just like a typical recursive make (building the
module and all sub-directories), while building any explicit target should also
build all dependencies of that target, even if they are in parent directories
(something typical recursive makes fail to do).

This is all inspired by/borrowing from 
https://github.com/aostruszka/nonrec-make/,
but without the symbolic links and separate Rules.mk files in each module 
directory.

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

Condtional target-specific variable assignment does not work as expected

2013-08-09 Thread Ed Hutchins 
The following Makefile:

condset: COND ?= one
condset: condset2
@echo $@ COND [$(COND)]

condset2: COND ?= two
condset2: condset3
@echo $@ COND [$(COND)]

condset3: COND ?= three
condset3:
@echo $@ COND [$(COND)]

outputs:

condset3 COND [three]
condset2 COND [two]
condset COND [one]

I would have expected "one" in all cases. Note that:

addset: COND += one
addset: addset2
@echo $@ COND [$(COND)]

addset2: COND += two
addset2: addset3
@echo $@ COND [$(COND)]

addset3: COND += three
addset3:
@echo $@ COND [$(COND)]

produces:

addset3 COND [one two three]
addset2 COND [one two]
addset COND [one]

The reason I need such a construct falls out of another shortcoming I've
run into while
trying to use make to manage the configuration of a set of servers
(basically a state machine):
there's no way to specify a true ordering-only constraint in gmake's
syntax. If there were a way
to specify a weak dependency (e.g. if "A" and "B" are both targets under
consideration, always
complete "B" before "A" without any other side-effects) I wouldn't need the
above. Unfortunately
the order-only dependency cannot be used for this in a reusable way.

In my case I'd like to have "init", "start" and "start_clean" end-user
targets which reuse common
targets which in turn depend on targets specified by the above semantic
intent. If there were a
true order-only operator (say ||), I could do:

.PHONY: 

init_server: 

start_server: 

start_clean_server: 

common: || init_server start_server start_clean_server

init: init_server common

start: start_server common

start_clean: start_server common

If I try the above with the current order-only | operator all three
dependencies are
invoked by common. Is there a way to get the effect of the above that
anyone can
think of?
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Condtional target-specific variable assignment does not work as expected

2013-08-09 Thread Ed Hutchins 
I've grossly simplified the above example to show the gist of it, but the
intermediate steps
are all first-order targets for debugging and development purposes. I
started using macros
but the amount of nesting and $-escaping needed makes that approach fragile
and hard for
non-expert users to manage (imagine a big team where different people are
responsible
for different phases of some complex process).



On Fri, Aug 9, 2013 at 1:53 PM, Philip Guenther  wrote:

> On Fri, Aug 9, 2013 at 12:59 PM, Ed Hutchins  wrote:
> ...
> > In my case I'd like to have "init", "start" and "start_clean" end-user
> > targets which reuse common
> > targets which in turn depend on targets specified by the above semantic
> > intent. If there were a
> > true order-only operator (say ||), I could do:
> >
> > .PHONY: 
> >
> > init_server: 
> > start_server: 
> > start_clean_server: 
> > common: || init_server start_server start_clean_server
> > init: init_server common
> > start: start_server common
> > start_clean: start_server common
> >
> > If I try the above with the current order-only | operator all three
> dependencies are
> > invoked by common. Is there a way to get the effect of the above that
> anyone can think of?
>
> Sounds to me like the commands currently in 'common' should be saved
> in a macro which is used by the 'init', 'start', and 'start_clean'
> targets and the 'common' target itself eliminated.  Indeed, the same
> may be true of 'init_server', 'start_server', and
> 'start_clean_server', particularly if they don't have any
> dependencies.  How is making them targets useful?
>
>
> Philip Guenther
>
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

feature request: $(wildcard) file type filter

2013-09-27 Thread Ed Hutchins 
I've recently come up with a nifty way to detect subdirectories:

ALLFILES := $(notdir $(wildcard $(d)/*))
# figure out which files are subdirs by wildcarding on /.
SUBDIRS := $(notdir $(patsubst %/.,%,$(wildcard $(addprefix
$(d)/,$(addsuffix /.,$(ALLFILES))

This is useful for scanning whole directory trees automatically, for example.

It would be a lot simpler to support posix find -type style qualifiers
on on $(wildcard):

$(wildcard [,])

where filter is 'f' for plain files, 'd' for directories, 'l' for links, etc.

  - Ed

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

feature request: $(wildcard) file type filter

2013-09-27 Thread Ed Hutchins 
I've recently come up with a nifty way to detect subdirectories:

ALLFILES := $(notdir $(wildcard $(d)/*))
# figure out which files are subdirs by wildcarding on /.
SUBDIRS := $(notdir $(patsubst %/.,%,$(wildcard $(addprefix
$(d)/,$(addsuffix /.,$(ALLFILES))

This is useful for scanning whole directory trees automatically, for example.

It would be a lot simpler to support posix find -type style qualifiers
on on $(wildcard):

$(wildcard [,])

where filter is 'f' for plain files, 'd' for directories, 'l' for links, etc.

  - Ed

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

.NOTPARALLEL as a dependency

2013-10-21 Thread Ed Hutchins 
I'm using a complex non-recursive make system to run test suites, some
subset of which are performance tests which should not run in
parallel.

Is there any way to get gmake to run a job serially? Ideally something like:

mytarget: .NOTPARALLEL

Currently I'm forced to either break up the test suite rules and run
the perf tests separately, or do something really ugly like:

EMPTY :=
COMMA := ,
SPACE := $(EMPTY) $(EMPTY)

# macros to get the job descriptor FDs
JSFDS = $(patsubst --jobserver-fds=%,%,$(filter --jobserver-fds=%,$(MAKEFLAGS)))
RJSFD = $(firstword $(subst $(COMMA),$(SPACE),$(JSFDS)))
WJSFD = $(lastword $(subst $(COMMA),$(SPACE),$(JSFDS)))

holdjobs:
+read -N7 -u$(RJSFD)

freejobs: $(ALLTS)
+echo -n '+++' >&$(WJSFD)

$(SERIAL_TESTS): holdjobs

freejobs: $(SERIAL_TESTS)

serialized_tests:  $(SERIAL_TESTS) freejobs

(the above works only for -j8, for example). As an aside is there any
way to determine the original -jN argument?

  - Ed

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

error with gmake: overriding macros

2001-02-15 Thread Nolan Ed-P1840C 


the attached makefile works with basic make routine on my unix box and
gmake.

make-f makefile.simdif mul0 ; # works
gmake   -f makefile.simdif mul0 ; # works

however, when I try to override the textmacro TIMING (defined in the
makefile) 

make TIMING=min -f makefile.simdif mul0; # make command properly overrides
the internally defined textmacro and executes the make.
gmake TIMING=min -f makefile.simdif mul0 ; #-- gmake command fails ERROR 2

 <> 

I have tried many different debug options and spent a bunch of time trying
to figure out why.  to no avail.. Is this a legitimate bug?


gmake -ver
GNU Make version 3.79, by Richard Stallman and Roland McGrath.
Built for hppa2.0n-hp-hpux11.00
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99
Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.



 makefile.simdif

Problem setting a variable inside a target

2023-09-24 Thread Ed L Wolf 
Hello

I am having some trouble trying to set a variable inside a target. When reading 
the variable, it comes up blank. Below is my make file code. The eval statement 
below highlighted in red is not working. Can you provide some assistance 
please? I am using GNU Make 4.1

$(DIR_A2LGEN_SETUP)/McData-setup.a2l: $(BSW_A2LS)  
$(DIR_SCRIPTS)/update_mcdata_a2l.py $(DIR_SCRIPTS)/update_copyright_info.py 
$(DIR_SCRIPTS)/merge_a2l_files.py $(DIR_TARGET)/$(PROJECT).odx-f 
$(DIR_A2L)/Merger.ini
@echo "A2L$@"

@rm -rf $(DIR_A2LGEN)
@rm -rf $(DIR_A2LLOGS)
@rm -rf $(DIR_A2LGEN_SETUP)
@rm -rf $(DIR_A2LGEN_UPDATE)
@rm -rf $(DIR_A2LGEN_MODIFY)
@rm -rf $(DIR_A2LGEN_CHECK)
@rm -rf $(DIR_A2LGEN_SUPPLIER)
@mkdir -p $(DIR_A2LGEN)
@mkdir -p $(DIR_A2LLOGS)
@mkdir -p $(DIR_A2LGEN_SETUP)
@mkdir -p $(DIR_A2LGEN_UPDATE)
@mkdir -p $(DIR_A2LGEN_MODIFY)
@mkdir -p $(DIR_A2LGEN_CHECK)
@mkdir -p $(DIR_A2LGEN_SUPPLIER)


@find $(DIR_BSWPROJECT) -type f -name "*.a2l" | xargs -i cp {} 
$(DIR_A2LGEN_SETUP)



#TODO: IS this still needed
@cp $(DIR_A2L)/_Master*.a2l $(DIR_A2LGEN_SETUP)

@python $(DIR_SCRIPTS)/update_mcdata_a2l.py $(DIR_A2LGEN_SETUP)

@python $(DIR_SCRIPTS)/update_copyright_info.py \
-a $(DIR_A2LGEN_SETUP)/McData.a2l.patched \
-o $(DIR_A2LGEN_SETUP)/McData-copyright.a2l


@python $(DIR_SCRIPTS)/merge_two_files.py \
-f1 $(CAN_A2L) \
-f2 $(DIR_A2LGEN_SETUP)/McData-copyright.a2l  \
-sp '/end DAQ'   \
-ep '/end IF_DATA'  \
-op $(DIR_A2LGEN_SETUP)/McData-copyright-can.a2l

# When there are no supplier a2l files then the merge process doesn't need to 
be done.

ifneq ($(wildcard $(DIR_SUPPLIER)),)
@find $(DIR_SUPPLIER) -type f -name "*.a2l" | xargs -i cp {} 
$(DIR_A2LGEN_SUPPLIER)
$(eval SUPPLIER_A2l := $(sort $(shell find $(DIR_A2LGEN_SUPPLIER) 
-type f -name "*.a2l")))
@echo "A2LSupplier folder detected"
@echo "Supplier a2l $(SUPPLIER_A2l)"


# Just becuase there is a supplier folder does not mean it has a2l files.
ifeq ($(SUPPLIER_A2l),"*.a2l")
@echo "A2LSupplier a2l files found"

@python $(DIR_SCRIPTS)/merge_a2l_files.py \
-s $(DIR_A2LGEN_SUPPLIER) \
-b a2l_file_list_supplier.opt \
-P $(DIR_A2L)/Merger.ini \
-M $(DIR_A2LGEN_SETUP)/McData-copyright-can.a2l \
-O $(DIR_A2LGEN_SETUP)/McData-setup.a2l \
-L $(DIR_A2LLOGS)/Log0-A2LMerger.log \
-g $(DIR_BUILDGEN)

@ASAP2Merger.exe \
@$(DIR_BUILDGEN)/a2l_file_list_supplier.opt \
> $(subst 
$(DIR_A2LGEN_SETUP),$(DIR_A2LLOGS),$(@:.a2l=.log)) \
|| echo "A2L
$(DIR_A2LLOGS)/Log0-A2L-Supplier-Merger.log - Check for warnings/errors!"


else
@cp $(DIR_A2LGEN_SETUP)/McData-copyright-can.a2l 
$(DIR_A2LGEN_SETUP)/McData-setup.a2l
@echo "A2LSupplier folder detected but no a2l files present"
endif

else
@cp $(DIR_A2LGEN_SETUP)/McData-copyright-can.a2l 
$(DIR_A2LGEN_SETUP)/McData-setup.a2l
@echo "A2LSupplier folder not available"
endif

Ed L Wolf
Technical Advisor - Embedded Software
e.l.w...@cummins.com
Cummins Inc.
Mail Code: C7004
1460 National Road
Columbus, Indiana 47201
United States

RE: Problem setting a variable inside a target

2023-09-25 Thread Ed L Wolf 
The following code response was


   Supplier folder detected



   Supplier folder detected but no a2l files present



but the response should have been



   Supplier folder detected



   Supplier a2l files found  since the folder DIR_SUPPLIER did exist 
and DIR_A2LGEN_SUPPLIER did have a file called Rte.a2l







Ed L Wolf
Technical Advisor - Embedded Software
e.l.w...@cummins.com
Cummins Inc.
Mail Code: C7004
1460 National Road
Columbus, Indiana 47201
United States

From: Martin Dorey 
Sent: Sunday, September 24, 2023 6:02 PM
To: Ed L Wolf ; bug-make@gnu.org
Subject: Re: Problem setting a variable inside a target

EXTERNAL SENDER: This email originated outside of Cummins. Do not click links 
or open attachments unless you verify the sender and know the content is safe.

> The eval statement below highlighted in red is not working

Perhaps you'd expect to see "BADGER is wombat" from:

mad@shuttle:~/tmp/wolf-2023-09-24$ cat Makefile
default:
  $(eval BADGER = wombat)
ifeq ($(BADGER),wombat)
  echo BADGER is wombat
else
  echo BADGER is not wombat
endif
mad@shuttle:~/tmp/wolf-2023-09-24$ make
echo BADGER is not wombat
BADGER is not wombat
mad@shuttle:~/tmp/wolf-2023-09-24$

If that wasn't what you were trying to convey, then perhaps you could concoct a 
similarly small example, including what you typed, what the computer said in 
response and what your expectation was.

If we look at the results of the first phase of Make described in:

https://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html

mad@shuttle:~/tmp/wolf-2023-09-24$ make -p nothing 2>&1 | grep -B2 -A1 BADGER
#  File has not been updated.
#  recipe to execute (from 'Makefile', line 2):
  $(eval BADGER = wombat)
  echo BADGER is not wombat

mad@shuttle:~/tmp/wolf-2023-09-24$

... then we see that the "BADGER is wombat" arm of the conditional is not even 
there to be run when it comes to executing the recipe in the second phase.  The 
ifeq was "immediate" but the $(eval) was "deferred".

It's a separate matter, but I fear your second red line might be expecting this 
behavior:

mad@shuttle:~/tmp/wolf-2023-09-24$ echo *.a2l
*.a2l
mad@shuttle:~/tmp/wolf-2023-09-24$

... which I doubt you're going to get from find(1):

mad@shuttle:~/tmp/wolf-2023-09-24$ find -name "*.a2l"
mad@shuttle:~/tmp/wolf-2023-09-24$


From: 
bug-make-bounces+martin.dorey=hds@gnu.org<mailto:bug-make-bounces+martin.dorey=hds@gnu.org>
 
mailto:bug-make-bounces+martin.dorey=hds@gnu.org>>
 on behalf of Ed L Wolf mailto:e.l.w...@cummins.com>>
Sent: Sunday, September 24, 2023 10:23
To: bug-make@gnu.org<mailto:bug-make@gnu.org> 
mailto:bug-make@gnu.org>>
Subject: Problem setting a variable inside a target

* EXTERNAL EMAIL *

Hello



I am having some trouble trying to set a variable inside a target. When reading 
the variable, it comes up blank. Below is my make file code. The eval statement 
below highlighted in red is not working. Can you provide some assistance 
please? I am using GNU Make 4.1



$(DIR_A2LGEN_SETUP)/McData-setup.a2l: $(BSW_A2LS)  
$(DIR_SCRIPTS)/update_mcdata_a2l.py $(DIR_SCRIPTS)/update_copyright_info.py 
$(DIR_SCRIPTS)/merge_a2l_files.py $(DIR_TARGET)/$(PROJECT).odx-f 
$(DIR_A2L)/Merger.ini

@echo "A2L$@"



@rm -rf $(DIR_A2LGEN)

@rm -rf $(DIR_A2LLOGS)

@rm -rf $(DIR_A2LGEN_SETUP)

@rm -rf $(DIR_A2LGEN_UPDATE)

@rm -rf $(DIR_A2LGEN_MODIFY)

@rm -rf $(DIR_A2LGEN_CHECK)

@rm -rf $(DIR_A2LGEN_SUPPLIER)

@mkdir -p $(DIR_A2LGEN)

@mkdir -p $(DIR_A2LLOGS)

@mkdir -p $(DIR_A2LGEN_SETUP)

@mkdir -p $(DIR_A2LGEN_UPDATE)

@mkdir -p $(DIR_A2LGEN_MODIFY)

@mkdir -p $(DIR_A2LGEN_CHECK)

@mkdir -p $(DIR_A2LGEN_SUPPLIER)





@find $(DIR_BSWPROJECT) -type f -name "*.a2l" | xargs -i cp {} 
$(DIR_A2LGEN_SETUP)







#TODO: IS this still needed

@cp $(DIR_A2L)/_Master*.a2l $(DIR_A2LGEN_SETUP)



@python $(DIR_SCRIPTS)/update_mcdata_a2l.py $(DIR_A2LGEN_SETUP)



@python $(DIR_SCRIPTS)/update_copyright_info.py \

-a $(DIR_A2LGEN_SETUP)/McData.a2l.patched \

-o $(DIR_A2LGEN_SETUP)/McData-copyright.a2l





@python $(DIR_SCRIPTS)/merge_two_files.py \

-f1 $(CAN_A2L) \

-f2 $(DIR_A2LGEN_SETUP)/McData-copyright.a2l  \

-sp '/end DAQ'   \

-ep '/end IF_DATA'  \

-op $(DIR_A2LGEN_SETUP)/McData-copyright-can.a2l



# When there are no supplier a2l files then the merge process doesn't need to 
be done.



ifneq ($(wildcard $(

RE: Problem setting a variable inside a target

2023-09-25 Thread Ed L Wolf 
One more comment. For some reason SUPLLIER_A2l is blank

Ed L Wolf
Technical Advisor - Embedded Software
e.l.w...@cummins.com
Cummins Inc.
Mail Code: C7004
1460 National Road
Columbus, Indiana 47201
United States

From: Ed L Wolf
Sent: Monday, September 25, 2023 6:10 AM
To: Martin Dorey ; bug-make@gnu.org
Subject: RE: Problem setting a variable inside a target

The following code response was


   Supplier folder detected



   Supplier folder detected but no a2l files present



but the response should have been



   Supplier folder detected



   Supplier a2l files found  since the folder DIR_SUPPLIER did exist 
and DIR_A2LGEN_SUPPLIER did have a file called Rte.a2l







Ed L Wolf
Technical Advisor - Embedded Software
e.l.w...@cummins.com<mailto:e.l.w...@cummins.com>
Cummins Inc.
Mail Code: C7004
1460 National Road
Columbus, Indiana 47201
United States

From: Martin Dorey 
mailto:martin.do...@hitachivantara.com>>
Sent: Sunday, September 24, 2023 6:02 PM
To: Ed L Wolf mailto:e.l.w...@cummins.com>>; 
bug-make@gnu.org<mailto:bug-make@gnu.org>
Subject: Re: Problem setting a variable inside a target

EXTERNAL SENDER: This email originated outside of Cummins. Do not click links 
or open attachments unless you verify the sender and know the content is safe.

> The eval statement below highlighted in red is not working

Perhaps you'd expect to see "BADGER is wombat" from:

mad@shuttle:~/tmp/wolf-2023-09-24$ cat Makefile
default:
  $(eval BADGER = wombat)
ifeq ($(BADGER),wombat)
  echo BADGER is wombat
else
  echo BADGER is not wombat
endif
mad@shuttle:~/tmp/wolf-2023-09-24$ make
echo BADGER is not wombat
BADGER is not wombat
mad@shuttle:~/tmp/wolf-2023-09-24$

If that wasn't what you were trying to convey, then perhaps you could concoct a 
similarly small example, including what you typed, what the computer said in 
response and what your expectation was.

If we look at the results of the first phase of Make described in:

https://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html

mad@shuttle:~/tmp/wolf-2023-09-24$ make -p nothing 2>&1 | grep -B2 -A1 BADGER
#  File has not been updated.
#  recipe to execute (from 'Makefile', line 2):
  $(eval BADGER = wombat)
  echo BADGER is not wombat

mad@shuttle:~/tmp/wolf-2023-09-24$

... then we see that the "BADGER is wombat" arm of the conditional is not even 
there to be run when it comes to executing the recipe in the second phase.  The 
ifeq was "immediate" but the $(eval) was "deferred".

It's a separate matter, but I fear your second red line might be expecting this 
behavior:

mad@shuttle:~/tmp/wolf-2023-09-24$ echo *.a2l
*.a2l
mad@shuttle:~/tmp/wolf-2023-09-24$

... which I doubt you're going to get from find(1):

mad@shuttle:~/tmp/wolf-2023-09-24$ find -name "*.a2l"
mad@shuttle:~/tmp/wolf-2023-09-24$


From: 
bug-make-bounces+martin.dorey=hds@gnu.org<mailto:bug-make-bounces+martin.dorey=hds@gnu.org>
 
mailto:bug-make-bounces+martin.dorey=hds@gnu.org>>
 on behalf of Ed L Wolf mailto:e.l.w...@cummins.com>>
Sent: Sunday, September 24, 2023 10:23
To: bug-make@gnu.org<mailto:bug-make@gnu.org> 
mailto:bug-make@gnu.org>>
Subject: Problem setting a variable inside a target

* EXTERNAL EMAIL *

Hello



I am having some trouble trying to set a variable inside a target. When reading 
the variable, it comes up blank. Below is my make file code. The eval statement 
below highlighted in red is not working. Can you provide some assistance 
please? I am using GNU Make 4.1



$(DIR_A2LGEN_SETUP)/McData-setup.a2l: $(BSW_A2LS)  
$(DIR_SCRIPTS)/update_mcdata_a2l.py $(DIR_SCRIPTS)/update_copyright_info.py 
$(DIR_SCRIPTS)/merge_a2l_files.py $(DIR_TARGET)/$(PROJECT).odx-f 
$(DIR_A2L)/Merger.ini

@echo "A2L$@"



@rm -rf $(DIR_A2LGEN)

@rm -rf $(DIR_A2LLOGS)

@rm -rf $(DIR_A2LGEN_SETUP)

@rm -rf $(DIR_A2LGEN_UPDATE)

@rm -rf $(DIR_A2LGEN_MODIFY)

@rm -rf $(DIR_A2LGEN_CHECK)

@rm -rf $(DIR_A2LGEN_SUPPLIER)

@mkdir -p $(DIR_A2LGEN)

@mkdir -p $(DIR_A2LLOGS)

@mkdir -p $(DIR_A2LGEN_SETUP)

@mkdir -p $(DIR_A2LGEN_UPDATE)

@mkdir -p $(DIR_A2LGEN_MODIFY)

@mkdir -p $(DIR_A2LGEN_CHECK)

@mkdir -p $(DIR_A2LGEN_SUPPLIER)





@find $(DIR_BSWPROJECT) -type f -name "*.a2l" | xargs -i cp {} 
$(DIR_A2LGEN_SETUP)







#TODO: IS this still needed

@cp $(DIR_A2L)/_Master*.a2l $(DIR_A2LGEN_SETUP)



@python $(DIR_SCRIPTS)/update_mcdata_a2l.py $(DIR_A2LGEN_SETUP)



@python $(DIR_SCRIPTS)/update_copyright_info.py \

-a $(DIR_A2LGEN_SETUP)/McData.a2l.patched \

-o $(DIR_A2

RE: Problem setting a variable inside a target

2023-09-26 Thread Ed L Wolf 
Here is the strip down version

$(DIR_A2LGEN_SETUP)/McData-setup.a2l: 
@echo "A2L$@"
 

@find $(DIR_BSWPROJECT) -type f -name "*.a2l" | xargs -i cp {} 
$(DIR_A2LGEN_SETUP)
 
 


ifneq ($(wildcard $(DIR_SUPPLIER)),)
@find $(DIR_SUPPLIER) -type f -name "*.a2l" | xargs -i cp {} 
$(DIR_A2LGEN_SUPPLIER)
$(eval SUPPLIER_A2l := $(sort $(shell find $(DIR_A2LGEN_SUPPLIER) 
-type f -name "*.a2l")))
@echo "A2LSupplier folder detected"
@echo "Supplier a2l $(SUPPLIER_A2l)"
 
 
# Just becuase there is a supplier folder does not mean it has a2l files. 
ifeq ($(SUPPLIER_A2l),"*.a2l")
@echo "A2LSupplier a2l files found"   

else
@cp $(DIR_A2LGEN_SETUP)/McData-copyright-can.a2l 
$(DIR_A2LGEN_SETUP)/McData-setup.a2l
@echo "A2LSupplier folder detected but no a2l files present"
endif
 
else 
@cp $(DIR_A2LGEN_SETUP)/McData-copyright-can.a2l 
$(DIR_A2LGEN_SETUP)/McData-setup.a2l
@echo "A2LSupplier folder not available"
endif

Ed L Wolf
Technical Advisor - Embedded Software
e.l.w...@cummins.com
Cummins Inc.
Mail Code: C7004
1460 National Road
Columbus, Indiana 47201
United States

-Original Message-
From: Bahman Movaqar  
Sent: Tuesday, September 26, 2023 6:35 AM
To: Ed L Wolf ; bug-make@gnu.org
Subject: Re: Problem setting a variable inside a target

EXTERNAL SENDER: This email originated outside of Cummins. Do not click links 
or open attachments unless you verify the sender and know the content is safe.


On Sun, 2023-09-24 at 17:23 +, Ed L Wolf wrote:

>
> ifneq ($(wildcard $(DIR_SUPPLIER)),)
> ...
> > $(eval SUPPLIER_A2l := $(sort $(shell find $(DIR_A2LGEN_SUPPLIER) - 
> > type f -name "*.a2l")))
> ...
> ifeq ($(SUPPLIER_A2l),"*.a2l")
>

Quickly skimming through your code, I can see that the above `ifneq'
and `ifeq' are evaluated at the very same time/pass.  That means the result of 
`eval' will not be visible to `ifeq'.

HTH,


PS: I could have tried to come up w/ an alternative approach to laying out the 
code but, I found the snippet crowded w/ too much logic specific to your case 
which makes it hard for me to see the abstract patterns in play.  Can you try 
to slim down the snippet and push it to a public repo somewhere so I can take a 
look?

--
Bahman

RE: Problem setting a variable inside a target

2023-09-26 Thread Ed L Wolf 
The problem is that $(eval SUPPLIER_A2l := $(sort $(shell find 
$(DIR_A2LGEN_SUPPLIER) -type f -name "*.a2l"))) runs before the directory was 
created and the a2l files were copied to the directory. Since this ran before 
the directory creation and copy  of the a2l file  SUPPLIER_A2L is always null. 
IS there anyway to force this statement to be ran in the exact sequence its 
listed?

Ed L Wolf
Technical Advisor - Embedded Software
e.l.w...@cummins.com
Cummins Inc.
Mail Code: C7004
1460 National Road
Columbus, Indiana 47201
United States

-Original Message-
From: Bahman Movaqar  
Sent: Tuesday, September 26, 2023 12:11 PM
To: Ed L Wolf ; bug-make@gnu.org
Subject: Re: Problem setting a variable inside a target

EXTERNAL SENDER: This email originated outside of Cummins. Do not click links 
or open attachments unless you verify the sender and know the content is safe.


OK, it took me a while but I think I may have something relatively more 
readable.

The idea is to let Make handle the prerequisites and the order of build for you 
by using well laid out targets.

The challenge I was facing trying to understand your code was that you'd 
condensed the original hierarchy of `*.a2l' files into `DIR_A2LGEN_SUPPLIER' 
which had made very difficult to tell Make how to make a target and when.

Here's my further slimmed down version of your snippet.  Let me know if that 
makes sense and whether it solves your problem.  You can also view on pastebin 
w/ syntax highlighting: https://pastebin.com/cHy8CuUt


🙶

SHELL := /usr/bin/env -S bash -o pipefail .DEFAULT_GOAL := all

###

ROOT := $(dir $(abspath $(lastword $(MAKEFILE_LIST build.dir := 
$(ROOT)build/ src.dir := $(ROOT)

###

A2L-files.src = $(shell find $(src.dir) -type f -name '*.a2l') A2L-files.dst = 
$(subst $(src.dir),$(build.dir),$(A2L-files.src))

###

$(build.dir) :
mkdir -p $(@)

###

$(build.dir)%.a2l : $(src.dir)%.a2l
mkdir -p $(build.dir)$(subst $(src.dir),,$(dir $(<))) \
&& cp $(<) $(@)

###

.PHONY : merge

ifneq ($(A2L-files.dst),)

merge : $(A2L-files.dst)
@echo MERGE POSSIBLE
@echo ...

else

merge :
@echo MERGE NOT POSSIBLE
@echo ...

endif

###

.PHONY : clean

clean :
-rm -rf $(build.dir)

###

.PHONY : all

all : | $(build.dir)
all : merge

🙷


--
Bahman


On Tue, 2023-09-26 at 12:17 +, Ed L Wolf wrote:
> Here is the strip down version
>
> $(DIR_A2LGEN_SETUP)/McData-setup.a2l:
> @echo "A2L$@"
>
>
> @find $(DIR_BSWPROJECT) -type f -name "*.a2l" | xargs -i 
> cp {} $(DIR_A2LGEN_SETUP)
>
>
>
>
> ifneq ($(wildcard $(DIR_SUPPLIER)),)
> @find $(DIR_SUPPLIER) -type f -name "*.a2l" | xargs -i cp 
> {} $(DIR_A2LGEN_SUPPLIER)
> $(eval SUPPLIER_A2l := $(sort $(shell find
> $(DIR_A2LGEN_SUPPLIER) -type f -name "*.a2l")))
> @echo "A2LSupplier folder detected"
> @echo "Supplier a2l $(SUPPLIER_A2l)"
>
>
> # Just becuase there is a supplier folder does not mean it has a2l 
> files.
> ifeq ($(SUPPLIER_A2l),"*.a2l")
> @echo "A2LSupplier a2l files
> found"
>
> else
> @cp $(DIR_A2LGEN_SETUP)/McData-copyright-can.a2l
> $(DIR_A2LGEN_SETUP)/McData-setup.a2l
> @echo "A2LSupplier folder detected but no a2l
> files present"
> endif
>
> else
> @cp $(DIR_A2LGEN_SETUP)/McData-copyright-can.a2l
> $(DIR_A2LGEN_SETUP)/McData-setup.a2l
> @echo "A2LSupplier folder not available"
> endif
>
> Ed L Wolf
> Technical Advisor - Embedded Software
> e.l.w...@cummins.com
> Cummins Inc.
> Mail Code: C7004
> 1460 National Road
> Columbus, Indiana 47201
> United States
>
> -Original Message-
> From: Bahman Movaqar 
> Sent: Tuesday, September 26, 2023 6:35 AM
> To: Ed L Wolf ; bug-make@gnu.org
> Subject: Re: Problem setting a variable inside a target
>
> EXTERNAL SENDER: This email originated outside of Cummins. Do not 
> click links or open attachments unless you verify the sender and know 
> the content is safe.
>
>
> On Sun, 2023-09-24 at 17:23 +, Ed L Wolf wrote:
>
> >
> > ifneq ($(wildcard $(DIR_SUPPLIER