Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 14 Dec 2006 22:10:49 +0100

On Thursday 14 December 2006 16:33, Janet Anderson wrote:
> I don't see the build problem.  The file 
> exampleApp/src/sncProgram.st is not part
> of  the product example, it is part of  the host product sncProgram.
>
> The file sncExample.stt is part of the product example and when I
> define SNCSEQ in the RELEASE file, build the ioc application, and
> then touch src/sncExample.stt and do a make the example (from
> PROD_IOC_vxWorks = example)
> is rebuilt.

Sorry, my fault: I tried to quick, quick reproduce my problem with the 
exampleApp, saw what I wanted to see and of course got it completely 
wrong. The original problem I had is this: a library is built by 
another application under the same top directory and the product that 
uses the library isn't rebuilt when the library changes.. But now when 
I try to reproduce my problem with the example app everything works 
there.... [hours later] ok, found the error, all my own fault: the line

	xxx_LIBS += yyy

was included from a makefile snippet that was generated. I made the 
error of including it at the end of the Makefile, i.e. /after/ including 
configure/RULES. Putting the include /before/ the RULES fixes 
everything. Ugh.

Anyway, there is one thing I'd like to remark on:

> Libraries outside the ioc application  will not be dependancies. The
> ioc application RELEASE file contains the following lines:
>
> # NOTE: The build does not check dependencies against files
> # that are outside this application, thus you should run
> # "gnumake distclean install" in the top directory each time
> # EPICS_BASE, SNCSEQ, or any other external module defined
> # in the RELEASE file is rebuilt.

I was aware of this. However, I dislike it pretty much, and I would like 
to ask what its rationale is.

The reason I dislike it is that "make distclean install" can take quite 
a long time for some of our applications. It is a pain to 
rebuild /everything/ just because I made a small fix in one of out 
drivers or device supports which would only require re-linking of some 
of the final executables. (I am in the middle of converting all our 
stuff from 3.13 to 3.14, including all our support modules, and this 
requires fixing things, recompilation, testing, on and on and on.)

Obviously the restriction is not there because it is hard to implement. 
Indeed, dependencies to all internal /and/ external libraries are 
already contained in the generated MakefileInclude. This can be seen if 
one dumps the value of the variable example_DEPLIBS (a list of the path 
names of /all/ libraries linked into the product); and then there is 
the line (also in MakefileInclude):

example$(EXE): $(example_OBJSNAME) $(example_RESS) $(example_DEPLIBS)

It even works (despite the disclaimer ;-) as I just tested:

ben@sarun: .../play/ioc-test > make -s
ben@sarun: .../play/ioc-test > 
touch /opt/epics/R3.14.8/base/lib/linux-x86/libCom.a*
ben@sarun: .../play/ioc-test > make -s
Installing library ../../../lib/linux-x86/libxxxSupport.a
Installing shared library ../../../lib/linux-x86/libxxxSupport.so
Installing binary ../../../bin/linux-x86/example

(Of course, I would need the same for header files, dbd and all else.)

Cheers
Ben
-- 
To the functional programmer's eye a loop is just a degenerate
form of linear recursion written in an adhoc special syntax.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System