Re: EPICS build problem/question

[Andrew Johnson <anj@aps.anl.gov>]

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