EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <2022 Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <2022
<== Date ==> <== Thread ==>

Subject: Re: Windows builds — can anyone explain this?
From: Andrew Johnson via Core-talk <core-talk at aps.anl.gov>
To: Freddie Akeroyd - STFC UKRI <freddie.akeroyd at stfc.ac.uk>, "core-talk at aps.anl.gov" <core-talk at aps.anl.gov>
Date: Tue, 8 Feb 2022 17:24:21 -0600

I just comitted 3a182a9 to fix this using quotes, which works on all architectures. That won't resolve all (most) of the "space in path" issues though, and you can't use paths wrapped in double-quote characters as prerequisites in GNUmake rules.

- Andrew


On 1/27/22 3:24 PM, Freddie Akeroyd - STFC UKRI via Core-talk wrote:

The problem is really due to resolving ambiguity on the command line, if you type    dir/s   do you mean the   dir   command with the   /s   option, or running   s.exe   in a folder called   dir? The command line (which Makefile lines with output redirection look to use) assumes the former in this case, meaning ../../../msi.exe  is interpreted as trying to run a program called “..”  with /../../msi.exe as command line flags. By using quotation marks, Ralph has highlighted the real executable and forced this to be resolved differently – I have confirmed that using      “$(MSI3_15)”    in the build rule also fixes the problem.  Using the make $(abspath) works as it seems starting with an initial / causes the command line to resolve the ambiguity the opposite way, so   c:/a/b/msi.exe   or   /a/b/msi.exe   are interpreted as we would wish and not as   /a.exe   with   /b/msi.exe   as command line options. One small bonus of the quotation mark approach is that if  $(abspath $(MSI3_15)) were to resolve to a path containing a space character I think it would fail, whereas the quotes would work fine, however other parts of the epics build system may also suffer with a space character in the build root directory and I think most people avoid spaces in directory names anyway   

 

Regards,

 

Freddie

 

From: Core-talk <core-talk-bounces at aps.anl.gov> On Behalf Of Johnson, Andrew N. via Core-talk
Sent: 27 January 2022 17:48
To: ralph.lange <ralph.lange at gmx.de>
Cc: EPICS core-talk <core-talk at aps.anl.gov>
Subject: Re: Windows builds — can anyone explain this?

 

On Jan 27, 2022, at 11:28 AM, Ralph Lange via Core-talk <core-talk at aps.anl.gov> wrote:

 

In the gtest module I am using

 

$(GTESTLISTS): %.list: %$(EXE)
 @$(RM) [email protected]
 "./$<" --gtest_list_tests > [email protected]
 

and as far as I recall I did add the double quotes for the same (or a similar) reason.

 

That’s an interesting alternative, I think Freddie’s explanations work for that solution too.



Careful about compatibility with both command.com and bash (MSYS2 et al).

 

Ack. It looks like we already solved this for the libcom programs using abspath:

 

CONFIG_LIBCOM_MODULE:YACC = $(abspath $(EPICS_BASE)/bin/$(EPICS_HOST_ARCH))/antelope$(HOSTEXE)

CONFIG_LIBCOM_MODULE:LEX = $(abspath $(EPICS_BASE)/bin/$(EPICS_HOST_ARCH))/e_flex$(HOSTEXE) \

 

My plan is to do that for the two database programs too, which don’t currently use abspath:

 

CONFIG_DATABASE_MODULE:MAKEBPT = $(abspath $(EPICS_DATABASE_HOST_BIN)/makeBpt$(HOSTEXE))

CONFIG_DATABASE_MODULE:MSI3_15 = $(abspath $(EPICS_DATABASE_HOST_BIN)/msi$(HOSTEXE))

 

Thanks,

 

- Andrew

 



On Thu, 27 Jan 2022 at 17:47, Johnson, Andrew N. via Core-talk <core-talk at aps.anl.gov> wrote:

Hi Freddie,

 

That’s great research and explanations, they make perfect sense and I have vague memories that GNUmake might do exactly what you say (on Windows at least, it has lots of special-cases for MS OSs), although I can’t find anything in the manual which describes that specifically.

 

I was considering using abspath when setting the MSI3_15 variable for the fix, you have validated that as a solution which I will therefore adopt.

 

Thanks a lot!

 

- Andrew

 



On Jan 26, 2022, at 7:13 PM, Freddie Akeroyd - STFC UKRI <freddie.akeroyd at stfc.ac.uk> wrote:

 

Well, maybe I have a guess – without output redirection make directly calls a C execute function that is happy with the executable having ../.. but when > is added make instead invokes the windows command interpreter and that is not happy with ../.. in the path

 

Freddie  

 

From: Akeroyd, Freddie (STFC,RAL,ISIS) 
Sent: 27 January 2022 01:07
To: Johnson, Andrew N. <anj at anl.gov>
Cc: core-talk at aps.anl.gov
Subject: RE: Windows builds — can anyone explain this?

 

The problem is the    > [email protected]   at the end of the first rule, if you remove this bit the rule will run OK with the existing ../.. in the path, but once output redirection is added that seems to stop working. Not sure why at the moment, or if there is an alternative syntax that might make it work here.

 

Freddie

 

From: Core-talk <core-talk-bounces at aps.anl.govOn Behalf Of Freddie Akeroyd - STFC UKRI via Core-talk
Sent: 27 January 2022 00:42
To: Johnson, Andrew N. <anj at anl.gov>
Cc: core-talk at aps.anl.gov
Subject: RE: Windows builds — can anyone explain this?

 

Sorry, I see you already said that – for some reason my outlook client put that sentence in a really small font at the end and I didn’t see it initially. Not sure why it works in one case and not the other, but will see if I can determine that

 

Freddie

 

From: Akeroyd, Freddie (STFC,RAL,ISIS) 
Sent: 27 January 2022 00:38
To: Johnson, Andrew N. <anj at anl.gov>
Cc: core-talk at aps.anl.gov
Subject: RE: Windows builds — can anyone explain this?

 

Hi Andrew,

 

I get that error in our builds too, but just for simmTest and nowhere else in the log. I can remove it by adjusting the path for MSI in the build rule with either

 

$(abspath $(MSI3_15)) -D $(DBFLAGS) -o $(COMMONDEP_TARGET) -S$< $(TEMPLATE_FILENAME) > [email protected]

 

Or

 

$(subst /,\,$(MSI3_15)) -D $(DBFLAGS) -o $(COMMONDEP_TARGET) -S$< $(TEMPLATE_FILENAME) > [email protected]

 

For some reason it doesn’t like ../..  at that time and errors at the first .. but giving it a ..\.. path instead works ok

 

Regards,

 

Freddie

 

From: Core-talk <core-talk-bounces at aps.anl.govOn Behalf Of Johnson, Andrew N. via Core-talk
Sent: 24 January 2022 23:47
To: EPICS core-talk <core-talk at aps.anl.gov>
Subject: Windows builds — can anyone explain this?

 

Here are 2 excerpts from the most recent APS Jenkins build log of the 7.0 tree on windows-x64 when it’s running msi.exe. Can anyone with Windows experience explain why the second call to msi succeeds without giving the same error as the first one? The first call happens while GNUmake is recreating its makefiles (which is what .d files really are) so the failure there isn’t supposed to stop the build. Do you see the same failure on your builds?

 

../../../../../../bin/windows-x64/msi.exe -D    -I. -I.. -I../O.Common -I../../../../../../db -o ../O.Common/simmTest.db -S../simmTest.substitutions  > simmTest.db.d
'..' is not recognized as an internal or external command,
operable program or batch file.

 

"Inflating database from ../simmTest.substitutions "
../../../../../../bin/windows-x64/msi.exe    -I. -I.. -I../O.Common -I../../../../../../db -o simmTest.db -S../simmTest.substitutions 
 
The error “'..' is not recognized as an internal or external command” happens when we use forward-slashes in a Windows command path, which we do above so I know that needs fixing, but why doesn’t it fail the second time we call msi.exe?
 

The build rules for the first command are:

 

%.db$(DEP): ../%$(SUBST_SUFFIX)

$(MSI3_15) -D $(DBFLAGS) -o $(COMMONDEP_TARGET) -S$< $(TEMPLATE_FILENAME) > [email protected]

 

and for the second:

 

$(COMMON_DIR)/%.db: ../%$(SUBST_SUFFIX)

$(ECHO) "Inflating database from $< $(TEMPLATE_FILENAME)"

@$(RM) $(notdir [email protected])

$(MSI3_15) $(DBFLAGS) -o $(notdir [email protected]) -S$< $(TEMPLATE_FILENAME)

 

Any ideas?

 

Thanks,

 

- Andrew

 

-- 

Complexity comes for free, simplicity you have to work for.

 

 

 

From: Core-talk <core-talk-bounces at aps.anl.govOn Behalf Of Johnson, Andrew N. via Core-talk
Sent: 24 January 2022 23:47
To: EPICS core-talk <core-talk at aps.anl.gov>
Subject: Windows builds — can anyone explain this?

 

Here are 2 excerpts from the most recent APS Jenkins build log of the 7.0 tree on windows-x64 when it’s running msi.exe. Can anyone with Windows experience explain why the second call to msi succeeds without giving the same error as the first one? The first call happens while GNUmake is recreating its makefiles (which is what .d files really are) so the failure there isn’t supposed to stop the build. Do you see the same failure on your builds?

 

../../../../../../bin/windows-x64/msi.exe -D    -I. -I.. -I../O.Common -I../../../../../../db -o ../O.Common/simmTest.db -S../simmTest.substitutions  > simmTest.db.d
'..' is not recognized as an internal or external command,
operable program or batch file.

 

"Inflating database from ../simmTest.substitutions "
../../../../../../bin/windows-x64/msi.exe    -I. -I.. -I../O.Common -I../../../../../../db -o simmTest.db -S../simmTest.substitutions 
 
The error “'..' is not recognized as an internal or external command” happens when we use forward-slashes in a Windows command path, which we do above so I know that needs fixing, but why doesn’t it fail the second time we call msi.exe?
 

The build rules for the first command are:

 

%.db$(DEP): ../%$(SUBST_SUFFIX)

$(MSI3_15) -D $(DBFLAGS) -o $(COMMONDEP_TARGET) -S$< $(TEMPLATE_FILENAME) > [email protected]

 

and for the second:

 

$(COMMON_DIR)/%.db: ../%$(SUBST_SUFFIX)

$(ECHO) "Inflating database from $< $(TEMPLATE_FILENAME)"

@$(RM) $(notdir [email protected])

$(MSI3_15) $(DBFLAGS) -o $(notdir [email protected]) -S$< $(TEMPLATE_FILENAME)

 

Any ideas?

 

Thanks,

 

- Andrew

 

-- 

Complexity comes for free, simplicity you have to work for.

 

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. 

 

-- 

Complexity comes for free, simplicity you have to work for.

 

 

-- 

Complexity comes for free, simplicity you have to work for.

 

-- 
Complexity comes for free, Simplicity you have to work for.

References:
Windows builds — can anyone explain this? Johnson, Andrew N. via Core-talk
RE: Windows builds — can anyone explain this? Freddie Akeroyd - STFC UKRI via Core-talk
RE: Windows builds — can anyone explain this? Freddie Akeroyd - STFC UKRI via Core-talk
RE: Windows builds — can anyone explain this? Freddie Akeroyd - STFC UKRI via Core-talk
RE: Windows builds — can anyone explain this? Freddie Akeroyd - STFC UKRI via Core-talk
Re: Windows builds — can anyone explain this? Johnson, Andrew N. via Core-talk
Re: Windows builds — can anyone explain this? Ralph Lange via Core-talk
Re: Windows builds — can anyone explain this? Johnson, Andrew N. via Core-talk
RE: Windows builds — can anyone explain this? Freddie Akeroyd - STFC UKRI via Core-talk

Navigate by Date:
Prev: Build failed: EPICS Base 7 base-7.0-466 AppVeyor via Core-talk
Next: epics-7.0 » linux32 - Build # 382 - Unstable! APS Jenkins via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <2022
Navigate by Thread:
Prev: RE: Windows builds — can anyone explain this? Freddie Akeroyd - STFC UKRI via Core-talk
Next: Build failed in Jenkins: EPICS-7 #395 Jenkins EPICS PSI via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <2022