Experimental Physics and
Industrial Control System

Kevin Peterson <[email protected]> · Thu, 18 Aug 2016 11:13:34 -0500

I doesn't appear that this build error is due to a bug in make.  I'm
using the following to build seq-2-2-3:

  Windows 7 (64-bit)
  Visual Studio 2010 Professional & Visual Studio 2015 Community Edition
  Make 4.1 (from the EPICS web site)
  Strawberry perl 5.20.3001

I see the build error when using base-3.15.4, but NOT when using
base-3.14.12.5.  Issuing "make" a second time does allow the build to
run to completion.

I'm hoping someone with knowledge of the changes to build rules between
base 3.14 and 3.15 can suggest a fix.

Kevin

On 10/4/15 9:27 AM, [email protected] wrote:
> Hi,
> 
> I have now run a build through on windows 10 (x64) using make 4.1 (from EPICS web site), base 3.15.2, seq 2.2.3, strawberry perl 5.22.0 (x64) and visual studio 2015. The sequencer files all compile OK and "make -s runtests" is successful, but I did encountered an error during the build process itself when it failed to generate "snl.bnf" - however after typing "make" a second time everything then runs to completion (the generated "snl.bnf" file is then blank though, but I believe this file is only used to generate documentation)
> 
> The build error is:
> 
> link -nologo  -debug -incremental:no -fixed:no /MACHINE:X64              -out:snc.exe       lexer.obj snl.obj main.obj node.obj var_types.obj analysis.obj gen_code.obj gen_ss_code.obj gen_tables.obj sym_table.obj builtin.obj type_check.obj     c:/dev/epics-base/lib/windows-x64-debug/Com.lib
> "Installing created executable ../../../bin/windows-x64-debug/snc.exe"
> ../Makefile:59: PATH_FILTER is deprecated; used for ../../../bin/windows-x64-debug/lemon.exe
> ../../../bin/windows-x64-debug/lemon.exe o=. -g ../snl.lem > ../O.Common/snl.bnf
> '..' is not recognized as an internal or external command,
> operable program or batch file.
> ../Makefile:59: recipe for target '../O.Common/snl.bnf' failed
> make[3]: *** [../O.Common/snl.bnf] Error 1
> make[3]: Leaving directory 'C:/dev/seq-2.2.3/src/snc/O.windows-x64-debug'
> c:/dev/epics-base/configure/RULES_ARCHS:61: recipe for target 'install.windows-x64-debug' failed
> make[2]: *** [install.windows-x64-debug] Error 2
> make[2]: Leaving directory 'C:/dev/seq-2.2.3/src/snc'
> c:/dev/epics-base/configure/RULES_DIRS:88: recipe for target 'snc.install' failed
> make[1]: *** [snc.install] Error 2
> make[1]: Leaving directory 'C:/dev/seq-2.2.3/src'
> c:/dev/epics-base/configure/RULES_DIRS:88: recipe for target 'src.install' failed
> make: *** [src.install] Error 2
> make: Leaving directory 'C:/dev/seq-2.2.3'
> 
> resulting in an empty snl.bnf    I can create a correct snl.bnf by manually running
> 
>     ..\..\..\bin\windows-x64-debug\lemon.exe o=. -g ..\snl.lem > ..\O.Common\snl.bnf
> 
> from my O.windows-x64-debug directory. If I happen to type instead
> 
>     ../../../bin/windows-x64-debug/lemon.exe
> 
> I get a " '..' is not recognized " error similar to above, which is a clue to what is happening. The problem seems to be caused by redirecting the output of the lemon command. The relevant Makefile line is:
> 
> $(COMMON_DIR)/snl.bnf: snl.lem
> 	$(LEMON) o=. -g $< > $@
> 
> if i remove the "> $@" and just create a blank snl.bnf
> 
> $(COMMON_DIR)/snl.bnf: snl.lem
> 	$(LEMON) o=. -g $<
> 	@echo > $(COMMON_DIR)/snl.bnf
> 
> then the build runs fine. If I use the windows native path instead of $(LEMON) in the original line with output redirection, it is fine too. So it seems that redirecting the output of the lemon command stops correct pathname translation on $(LEMON) prior to passing the command to windows, which I guess is a "make" bug?
> 
> Regards,
> 
> Freddie
> 
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System