EPICS Controls Argonne National Laboratory

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: Ralph Lange via Core-talk <core-talk at aps.anl.gov>
To: EPICS Core Talk <core-talk at aps.anl.gov>
Date: Thu, 27 Jan 2022 18:28:58 +0100
FWIW,

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.
Careful about compatibility with both command.com and bash (MSYS2 et al).

Cheers,
~Ralph


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.gov> On 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.gov> On 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.gov> On 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.


Replies:
Re: Windows builds — can anyone explain this? Johnson, Andrew N. via Core-talk
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

Navigate by Date:
Prev: Build failed in Jenkins: epics-pvData-mac #200 APS Jenkins via Core-talk
Next: Re: Windows builds — can anyone explain this? Johnson, Andrew N. 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? Johnson, Andrew N. via Core-talk
Next: Re: Windows builds — can anyone explain this? Johnson, Andrew N. 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
ANJ, 14 Sep 2022 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·