| 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | RE: Windows builds — can anyone explain this? |
| From: | Freddie Akeroyd - STFC UKRI via Core-talk <core-talk at aps.anl.gov> |
| To: | "Johnson, Andrew N." <anj at anl.gov> |
| Cc: | "core-talk at aps.anl.gov" <core-talk at aps.anl.gov> |
| Date: | Thu, 27 Jan 2022 00:38:22 +0000 |
|
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) > $@ Or $(subst /,\,$(MSI3_15)) -D $(DBFLAGS) -o $(COMMONDEP_TARGET) -S$< $(TEMPLATE_FILENAME) > $@ 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 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) @$(RM) $@ $(MSI3_15) -D $(DBFLAGS) -o $(COMMONDEP_TARGET) -S$< $(TEMPLATE_FILENAME) > $@ and for the second: $(COMMON_DIR)/%.db: ../%$(SUBST_SUFFIX) $(ECHO) "Inflating database from $< $(TEMPLATE_FILENAME)" @$(RM) $(notdir $@) $(MSI3_15) $(DBFLAGS) -o $(notdir $@) -S$< $(TEMPLATE_FILENAME) @$(MV) $(notdir $@) $@ 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 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?
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:
and for the second:
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. |