On Wednesday 21 December 2005 18:34, Emmanuel Mayssat wrote:
> The build system is quite frustrating for new comers.
> The makefile includes files which themselves include other files.
And so on. However, this is something that is hard to avoid, due to the
sheer number of supported host and target systems, compilers, etc. It's
a combinatorial explosion which can only be tamed by aggressive
(re-)factoring. This tends to lead to a lot of separate files and many
complex and strangely nested make variable definitions.
The one /real/ weakness of EPICS' build system is that it (still)
heavily uses recursive make, with all the by now well-known problems
this causes, particularly for large applications that consist of many
inter-dependent modules. (Those problems are due to the artificial
fragmentation of the dependency graph caused by recursive make).
> So quite tricky to understand the details, specifically when it
> doesn't build.
>
> If you don't want to know about the build system, then we have
> something in common ;-)
I wholeheartedly agree, however...
> My advice to you is that instead of modifying your Makefile, you may
> want to change your environment and use the gmake -e option.
>
> That way you will be able
> 1/ to keep the original files in the base
> ( very useful if you want to upgrade epics very easily or build
> several base in different directories, etc.)
The standard (=recommended) way to achieve this is to import the sources
into your own CVS repo, and merge your local changes into new versions.
> 2/ You can keep track of your change
See above. CVS works even better ;-)
> 3/ you can automate the build process in scripts
Well, typing 'make' is as automated as it gets, I'd say. And you'll have
to maintain those scripts. The Make-System evolves even over minor
EPICS revisions, some variables may disappear others may be added. Your
build script inevitably either suffers bit-rot, or gets more and more
complicated each time you add a new EPICS version to your site. My
humble opinion is that maintaining shell scripts is even more of a
nightmare than maintaining makefiles, but YMMV. Oh, and don't assume
everyone will upgrade their every application to use the latest EPICS
release as soon as you install it. They won't. They'll tell you that
it's too long ago since they wrote it, they have more pressing work to
do, it works fine so why change it etc.etc. unless you /force/ them to
do it by deleting the old EPICS version and then they'll just hate
you ;)
Anyway, it was a deliberate decision in the design of the EPICS build
system to keep every <top> module (application) as self-contained as
possible. If you avoid deleting, renaming, or moving old versions of
support modules (including base), and instead always place new versions
beside old ones, you can build even ancient applications right out of
the box. Well, that's the theory, at least...
Ben
- References:
- epics extension Christophe Moins
- Re: epics extension Andrew Johnson
- Re: epics extension Emmanuel Mayssat
- Navigate by Date:
- Prev:
RE: record field definition and float Lawrence T. Hoff
- Next:
about using NI-1014 with VME/Linux Jun-ichi Odagiri
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: epics extension Emmanuel Mayssat
- Next:
record field definition and float Liyu, Andrei
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|