Re: Windows builds — can anyone explain this?

[Ralph Lange via Core-talk <core-talk at aps.anl.gov>]

FWIW,

In the gtest module I am using

$(GTESTLISTS): %.list: %$(EXE)

	@$(RM) $@

	"./$<" --gtest_list_tests > $@

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    > $@   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) > $@

 

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
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)

@$(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
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)

@$(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.

 

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.