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