EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: EPICS build problem/question
From: "Mark Rivers" <[email protected]>
To: "Andrew Johnson" <[email protected]>, "Core-Talk" <[email protected]>
Cc: [email protected]
Date: Mon, 27 Oct 2008 11:31:12 -0500

Andrew and Janet,

 

> You are unfortunately in rather uncharted territory;

> we haven't really worked

> much on the case of building for Windows in the same tree as for other

> targets, as you're finding out, partly because as Ron Sluiter said it takes

> ages (although I think that may have changed recently since they just

> upgraded Samba on our file servers).  I have compiled for cygwin-x86 in the

> same tree, but not for win32-x86.

 

This may be uncharted territory for many developers, but I have been building win32-x86 and linux-x86 in the same tree for 4 years without a problem (I just searched my old development trees to establish that I have been doing it since at least December 2004).  I have never had a problem.

 

I was just able to prove that this problem did not exist in 3.14.8.2, it only happens when I moved to 3.14.10.

 

The synApps module "dxp" is one that is giving me a problem.  I have the identical code for "dxp" in a tree with EPICS_BASE defined as 3.14.8.2 and in another tree with EPICS_BASE defined as 3.14.10.

 

I both trees I just did the following in this order:

 

- On win32-x86 "make clean uninstall"

- On linux-x86 (and vxWorks) "make clean uninstall"

- On win32-x86 "make"

- On linux-x86 "make"

 

In the 3.14.8.2 tree this works fine.

 

In the 3.14.10 tree the linux-x86 build fails with the following error:

 

make -C O.linux-x86 -f ../Makefile TOP=../../.. T_A=linux-x86 install

make[3]: Entering directory `/home/epics/devel/dxp/2-8-1/dxpApp/src/O.linux-x86'

../O.Common/dxp.dbd.depends:3: *** target pattern contains no `%'.  Stop.

make[3]: Leaving directory `/home/epics/devel/dxp/2-8-1/dxpApp/src/O.linux-x86'

make[2]: *** [install.linux-x86] Error 2

make[2]: Leaving directory `/home/epics/devel/dxp/2-8-1/dxpApp/src'

make[1]: *** [src.install] Error 2

make[1]: Leaving directory `/home/epics/devel/dxp/2-8-1/dxpApp'

make: *** [dxpApp.install] Error 2

 

 

So the problem file is O.Common.dxp.dbd.depends.  On 3.14.8.2. this file contains the following:

 

*******************

corvette:~/devel/dxp/2-8-1>more ../../../devel_old/dxp/2-8-1/dxpApp/src/O.Common/dxp.dbd.depends

# DO NOT EDIT: This file created by mkmf.pl,v 1.5 2002/03/25 21:33:24 jba Exp $

 

../O.Common/dxp.dbd : ../dxpSupport.dbd ../dxpRecord.dbd

 

#Depend files must be targets to avoid 'No rule to make target ...' errors

../dxpSupport.dbd :

../dxpRecord.dbd :

******************

 

On 3.14.10 this file contains the following:

 

corvette:~/devel/dxp/2-8-1>more dxpApp/src/O.Common/dxp.dbd.depends

# DO NOT EDIT: This file created by mkmf.pl,v 1.5 2002/03/25 21:33:24 jba Exp $

 

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/base.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/asyn.dbd

../O.Common/dxp.dbd : J:/epics/devel/mca/6-10/dbd/mcaSupport.dbd

../O.Common/dxp.dbd : J:/epics/devel/calc/2-6-5beta/dbd/calcSupport.dbd

../O.Common/dxp.dbd : J:/epics/devel/sscan/2-6-2/dbd/sscanSupport.dbd

../O.Common/dxp.dbd : J:/epics/devel/autosave/4-4beta/dbd/asSupport.dbd

../O.Common/dxp.dbd : ../dxpSupport.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuGlobal.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuConvert.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/aiRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/aoRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/aSubRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/biRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/boRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/calcRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/calcoutRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/compressRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/dfanoutRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/eventRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/fanoutRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/longinRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/longoutRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/mbbiRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/mbbiDirectRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/mbboRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/mbboDirectRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/permissiveRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/selRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/seqRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/stateRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/stringinRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/stringoutRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/subRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/subArrayRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/waveformRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/devSoft.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/asynRecord.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/devEpics.dbd

../O.Common/dxp.dbd : J:/epics/devel/mca/6-10/dbd/mcaRecord.dbd

../O.Common/dxp.dbd : J:/epics/devel/calc/2-6-5beta/dbd/transformRecord.dbd

../O.Common/dxp.dbd : J:/epics/devel/calc/2-6-5beta/dbd/sCalcoutRecord.dbd

../O.Common/dxp.dbd : J:/epics/devel/calc/2-6-5beta/dbd/aCalcoutRecord.dbd

../O.Common/dxp.dbd : J:/epics/devel/calc/2-6-5beta/dbd/swaitRecord.dbd

../O.Common/dxp.dbd : J:/epics/devel/sscan/2-6-2/dbd/busyRecord.dbd

../O.Common/dxp.dbd : J:/epics/devel/sscan/2-6-2/dbd/scanparmRecord.dbd

../O.Common/dxp.dbd : J:/epics/devel/sscan/2-6-2/dbd/sscanRecord.dbd

../O.Common/dxp.dbd : ../dxpRecord.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuAlarmSevr.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuAlarmStat.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuCompress.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuFtype.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuIvoa.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuOmsl.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuPriority.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuScan.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuYesNo.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/menuSimm.dbd

../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/dbCommon.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/devAsynOctet.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/devAsynInt32.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/devAsynInt8Array.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/devAsynInt16Array.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/devAsynInt32Array.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/devAsynFloat64.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/devAsynFloat32Array.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/devAsynFloat64Array.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/devAsynUInt32Digital.dbd

../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/devAsynRecord.dbd

../O.Common/dxp.dbd : J:/epics/devel/sscan/2-6-2/dbd/sscanMenu.dbd

 

So only in 3.14.10 does that file contain absolute paths that are causing the problems.

 

Mark

 

 

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]]
Sent: Friday, October 24, 2008 3:54 PM
To: Mark Rivers; Core-Talk
Cc: Janet Anderson; [email protected]
Subject: Re: EPICS build problem/question

 

Hi Mark,

 

On Friday 24 October 2008 13:49:34 Mark Rivers wrote:

> 

> I've found another problem with the build system that I believe is new

> to 3.14.10.

 

You are unfortunately in rather uncharted territory; we haven't really worked

much on the case of building for Windows in the same tree as for other

targets, as you're finding out, partly because as Ron Sluiter said it takes

ages (although I think that may have changed recently since they just

upgraded Samba on our file servers).  I have compiled for cygwin-x86 in the

same tree, but not for win32-x86.

 

> I built my application directory for win32-x86.  I then did a build in

> the same application directory for linux-x86.

 

> ../O.Common/dxp.dbd.depends:3: *** target pattern contains no `%'.

> Stop.

 

> I looked at the O.Common/dxp.dxd.depends and it contains the following:

> 

> ../O.Common/dxp.dbd : H:/epics/base-3.14.10/dbd/base.dbd

> ../O.Common/dxp.dbd : J:/epics/devel/asyn/4-10/dbd/asyn.dbd

 

When we create/compile many kinds of objects we also generate the depends file

in the same directory, which in your case generated filenames with windows

drive letters in as you saw.  The generated depends files are interpreted by

gnumake after the Makefile, and in your case gnumake on linux is parsing the

drive specification in the dependency as a static pattern rule since it

doesn't expect to see colons in filenames.

 

Here is the syntax of a static pattern rule:

     TARGETS ...: TARGET-PATTERN: PREREQ-PATTERNS ...

             COMMANDS

             ...

 

We probably shouldn't be creating depends files in the O.Common directory

since the actual dependencies could be different for different targets, but

currently we do, and this isn't something that we can change easily.  I don;t

know how hard it would be to create those depends files in the O.<target>

directory, which is the obvious place to put them if we can.  This is too

late for R3.14.10 though.

 

> This is a serious problem if I want to use the same tree for both Linux

> and Windows builds.  This used to work fine in 3.14.8.2, but now I get

> errors on Linux if the previous build was Windows.

 

Could you have been using a different version of gnumake or Perl for 3.14.8.2? 

I suspect you were just lucky.

 

> The only way around this I can see is to do a complete rebuild (e.g.

> make clean.linux-x86) of the application tree (e.g. all of synApps) on

> Linux if the previous build was Windows, rather than just doing a quick

> update build of things that have changed.

 

Or use a different source tree for building on Windows.

 

I have discussed the idea of dropping the O.Common directory with Janet

before, and installing all DBD files into target architecture subdirectories

under <top>/dbd.  This would permit us to add target-specific conditionals

into DBD files, which I think you have asked for in the past, but it would

slow down every multi-target build since every architecture would have to

generate every file that is currently created just once in O.Common.

 

I really wouldn't want to have to do the same thing for <top>/db as well, just

because of the sheer number of .db files that exist, but the problem is that

a few DB files are going to be using specific devices or record types which

are only present in the DBD files of certain architectures.

 

Most sites don't currently have this problem (because nobody else builds for

Windows in the same tree), and we'd be penalizing everyone if we make this

change.  This is a step which I'm reluctant to take just to make life easier

for a small number of users.

 

Maybe we could rename the O.Common directory to O.$(OS_CLASS) so Windows would

use a different directory; we'd still be generating more versions but fewer

than one per target arch in most cases.

 

I would welcome comments from other core developers on this issue.

 

- Andrew

--

Talk is cheap. Show me the code. -- Linus Torvalds


Replies:
Re: EPICS build problem/question Andrew Johnson
References:
Re: EPICS build problem/question Andrew Johnson

Navigate by Date:
Prev: Re: EPICS build problem/question Andrew Johnson
Next: Re: EPICS build problem/question Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: EPICS build problem/question Andrew Johnson
Next: Re: EPICS build problem/question Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·