Subject: |
Re: converting from R3.13.0Beta12 to R3.13.8 |
From: |
Nick Rees <[email protected]> |
To: |
"tech-talk (E-mail)" <[email protected]> |
Date: |
Tue, 4 Mar 2003 09:33:04 -1000 (HST) |
All,
I have just talked to Kevin on the phone about this. We still use UAE at
the JAC because the EPIC's build still doesn't interoperate well with
other configuration/build systems and it still hardwires the TOP link in
the Makefile's, and so eliminates much of the flexibility we require when
sharing our cvs repository with our development sites around the world.
One of the primary UAE requirements was that the directories be position
independent.
However, UAE still uses virtually all the normal EPIC's build rules in the
make - it just provides additional rules to propogate the make whilst
keeping track of the path to the top of the application in the first pass
through. Currently this is done with a modified version of RULES_DIRS that
is the make propogator. In every directory it basically does:
foreach dir in sub-directories
generate $dir/Makefile with TOP=$(TOP)/..
make -C $dir
end
The sub-directories are determined by the presence of the files
Makefile.Host, Makefile.Vx and Makefile.Dirs in the parent directory.
Since there are no Makefile's in the cvs repository, the make can co-exist
with other make systems which generate the Makefiles as part of a
configuration stage (e.g. Perl, gnu configure, XWindows mkmf - all of
which we have cause to use). Unfortunately, I saw that makeBaseApp has
gone the other way I see, so I suspect that if UAE is to co-exist with the
3.14 build files, the Makefiles will have to be named Makefile.Epics, not
Makefile.
So, if people are still interested in using UAE, the relevant link is:
http://www.jach.hawaii.edu/JACpublic/UKIRT/software/epics
Cheers,
--
Nick Rees
Head of Software and Computing Services
Joint Astronomy Centre Ph: +1 (808) 961-3756
660 N. Aohoku Place Fax: +1 (808) 961-6516
Hilo, HI. 96720 Email: [email protected]
- References:
- Re: converting from R3.13.0Beta12 to R3.13.8 Marty Kraimer
- Navigate by Date:
- Prev:
Re: Any modern solution besides the TVs and EPICS alarm handler ? Geoff Savage
- Next:
Re: Long expressions using MAX and MIN in CALC fields Tim Mooney
- 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: converting from R3.13.0Beta12 to R3.13.8 Marty Kraimer
- Next:
Any modern solution besides the TVs and EPICS alarm handler ? Feng, Shuchen
- 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
|