Experimental Physics and
Industrial Control System

<[email protected]> · Tue, 10 Aug 2010 11:25:55 +0100

Hi Andrew,

The 'W:\..' backward slash was a result of some trouble I had initially
when working in R3.14.10 on Windows. We use the EPICS build system
macros to expand paths into some batch scripts and at the time I needed
at least the first slash in a Windows path to be a backward one. This
worked (and still works) fine on R3.14.10. However, now I have started
using the @VAR@ expansion to create my batch scripts and no longer
specifically need the backward slash (I think...) Using the forward
slash does not change the behaviour in checkRelease.

I have also tried putting the SNCSEQ and ASYN macros in the
RELEASE.win32-x86 file as you suggest -but it still fails.

I have attached a tar file with the minimal example I'm working on. I
just change the R3.14.10 and R3.14.11 parts over in the RELEASE files to
try one version or another (and run it as "convertRelease.pl -T .. -a
win32-x86 checkRelease" in two appropriately configured shells for each
EPICS version).

By putting in a few print statements in the convertRelease.pl script
checkRelease function (see attached) I can trace where it get to before
falling over. For R3.14.11 I get:

W:\work\up45\dummy\configure>convertRelease.pl -T .. -a win32-x86
checkRelease
  SNCSEQ:       W:/prod/R3.14.11/support/seq/2-0-12dls1
        PVTKL   - FALSE
        EPICS_BASE      - W:\epics/R3.14.11/base
        PVFILE  - FALSE
        PVCA    - TRUE
        TEMPLATE_TOP    -
/dls_sw/epics/R3.14.11/base/templates/makeBaseApp/top
  ASYN: W:/work/R3.14.11/support/asyn
        SNCSEQ  - W:\prod/R3.14.11/support/seq/2-0-12dls1
        EPICS_BASE      - W:\epics/R3.14.11/base
        SUPPORT         - W:\prod/R3.14.11/support
        LINUX_GPIB      - NO
  EPICS_BASE:   W:/epics/R3.14.11/base
  WORK: W:/work/R3.14.11/support
        EPICS_BASE      - /dls_sw/epics/R3.14.11/base
/dls_sw/epics/R3.14.11/base: No such file or directory at
W:\work\up45\dummy\base3.14.11bin\convertRelease.pl line 209

... And for R3.14.10 I get:

W:\work\up45\dummy\configure>convertRelease.pl -T .. -a win32-x86
checkRelease
  SNCSEQ:       W:/prod/R3.14.10/support/seq/2-0-12
        PVTKL   - FALSE
        EPICS_BASE      - W:\epics/R3.14.10/base
        PVFILE  - FALSE
        PVCA    - TRUE
        TEMPLATE_TOP    -
/dls_sw/epics/R3.14.10/base/templates/makeBaseApp/top
  ASYN: W:/prod/R3.14.10/support/asyn/4-12
        SNCSEQ  - W:\prod/R3.14.10/support/seq/2-0-12
        EPICS_BASE      - W:\epics/R3.14.10/base
        SUPPORT         - W:\prod/R3.14.10/support
        LINUX_GPIB      - NO
  EPICS_BASE:   W:/epics/R3.14.10/base
  WORK: W:/work/R3.14.10/support
  SUPPORT:      W:/prod/R3.14.10/support

I think you're right that abs_path() just dies (the croak() function you
mention presumably) in R3.14.11 when going through WORK or SUPPORT
macros - but in R3.14.10 when going through the SUPPORT or WORK macro,
we don't even get into the while loop (line 207) where the abs_path() is
called...   Unfortunately my perl skills are limited at best (I'm more
of a python-person...) and I can't figure out why it gets there. Any
ideas?

Cheers,
Ulrik

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]] 
Sent: 09 August 2010 17:23
To: [email protected]
Cc: Pedersen, Ulrik (DLSLtd,RAL,DIA)
Subject: Re: checkRelease on Windows

Hi Ulrik,

On Monday 09 August 2010 09:49:01 [email protected] wrote:
>
> perl W:\epics/R3.14.11/base/bin/win32-x86/convertRelease.pl 
> checkRelease
> /dls_sw/epics/R3.14.11/base: No such file or directory at 
> W:\epics/R3.14.11/base/bin/win32-x86/convertRelease.pl line 208

That error message is coming from the abs_path() subroutine which calls
croak() if its path argument doesn't exist, which is obviously doesn't.
What I can't see is why there would be any change in behaviour between
3.14.10 and 3.14.11, since there were virtually no relevant code changes
between these two versions.

> The same modules with the same RELEASE files used to build OK on 
> R3.14.10 - but not anymore.

Are you sure that your RELEASE.win86-x32 file paths used 'W:\...' under
3.14.10, and not 'W:/...' (forward vs. backward slash)?  That is one
thing that I'd want to see changed in case it matters.  I can't think
what else might be causing a behaviour change.

> After playing around with the macros in the RELEASE and
> RELEASE.win32-x86 I found that if I don't use the macro expansion (so 
> delete the WORK= and SUPPORT= macros and put all dependencies with 
> full paths in both RELEASE files) it works and checkRelease completes.

> This leads me to think that the perl scripts (or makefile?) that 
> expand macros is doing something different from R3.14.10...? However, 
> I have not been able to trace down any changes in base that seems 
> relevant to my problem.

Another possibility that might work would be to restore the WORK and
SUPPORT macros, and also add SNCSEQ and ASYN macros into your
RELEASE.win32-x86 file so it completely duplicates the RELEASE file.  I
suspect what's happening is that the macro values are being expanded
immediately on definition in the RELEASE file, so when the WORK and
SUPPORT macros that they're supposed to depend on are changed this
doesn't modify the values of SNCSEQ and ASYN.

I implemented := and ?= towards the end of last year, and those changes
will appear in R3.14.12.  The := operator expands any macros on its
right-hand side on definition, whereas the original = assignment isn't
supposed to expand any macros in its value until they are actually used
(the Release.pm module now implements = properly as well).  ?= only sets
a value if the variable is currently undefined.  Both assignments have
been supported by GNU make for some time, but the release file parser
didn't understand them so they weren't allowed in release files before
now.

HTH,

- Andrew
--
The best FOSS code is written to be read by other humans -- Harald Welte

-- 

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.

Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 

Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.

Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System