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: | Windows builds — can anyone explain this? |
From: | "Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov> |
To: | EPICS core-talk <core-talk at aps.anl.gov> |
Date: | Mon, 24 Jan 2022 23:46:39 +0000 |
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:
and for the second:
Any ideas?
Thanks,
- Andrew
--
Complexity comes for free, simplicity you have to work for.
|