> -----Original Message-----
> Hi Lewis,
>
> On Wednesday 08 December 2010 14:20:38 J. Lewis Muir wrote:
> > On 12/8/10 2:06 PM, Andrew Johnson wrote:
> > > Michael suggested replacing our build system with CMake, but he
did
> find
> > > some issues with doing so and I don't think that's up to the job,
> and it
> > > was not popular in my recent survey (aside from the effort needed
> to
> > > train and support all of the EPICS developers out there in any new
> > > system).
> >
> > I'd be curious to know what the issues were and why you don't think
> it's
> > up to the job.
The main "issue" was/is that there didn't seem to be much interest.
Basically this is too big a job for one person. If you have
time/interest in working on this please let me know. I am more than
happy to help you get started.
What I have so far is for building Base only. The next big task is
expanding to build support modules. Most of the mechanics are there
since it already builds the softIoc executable. The work is in
packaging things properly.
> Ok, maybe instead of "it's not up to the job" I should have said "the
> result
> would not be as easy for developers to configure as the current build
> system".
Actually I would argue that it would be much easier. The syntax is more
C-like and it reads linearly. It does more error checking and has
standard diagnostics. It does system introspection like autoconf so,
for example, if you don't have the motif headers installed it will
detect this during the configure phase and give a useful error.
Instead of
LIBRARY = name
name_SRCS += ...
You have
add_both_library(Com
SONUM ${BASE_SOVERSION}
SOURCES ${COM_SRCS}
LINK_LIBRARIES ${LIB_DEPS}
EXTRA_LIB ${CMAKE_THREAD_LIBS_INIT}
${LDADD}
)
Where everything is given together and you don't have to go hunting.
Also it can build more than one library in a directory.
Btw. add_both_library() is a macro which creates targets for both build
and install. For IOC I would imagine something like:
add_ioc(myapp
SOURCES *.cpp
LINK_LIBRARIES asyn
DBD asyn.dbd someother.dbd
)
Oh, and you can put
MESSAGE(STATUS "Some string ${with} variables")
Anywhere to help with debugging.
> Michael is the best person to say what the issues were, but I'm pretty
> sure
> that he only had it working on Linux and RTEMS.
And windows (mingw).
Although cygwin shouldn't require much effort. Various other *nix
targets (eg. solaris w/ suncc) are also supported by cmake so supporting
them is straight forward.
vxWorks would be the difficult part. Especially since I lack the
resources/inclination to support it. With RTEMS I can use pkg-config to
detect CFLAGS and such for any BSP automatically, but I don't expect
vxWorks has anything similar.
> I don't know whether
> CMake
> runs on all our host architectures, but I'm guessing that supporting
> the
> Microsoft compiler on Windows might take some work; one criterion that
> I will
> insist on is that we not drop any major targets.
All these and more...
Can't find a list on the web right now, but if you have cmake installed
look in /usr/share/cmake-*/Modules/Platform/
> You can find Michael's latest version on Launchpad, browse it here:
> http://bazaar.launchpad.net/~mdavidsaver/epics-base/cmake/files
>
> One example about the complexity issue, the CMakeLists.txt files in
his
> src/*
> directories do seem to be longer than their companion Makefiles.
Please keep in mind that CMake does a more (host introspection) so # of
lines isn't an exact comparison. Also I am spreading things around a
lot more then I need to for readability.
That said, to support Linux, Windows (mingw), and RTEMS and build Base
takes 3k lines of CMake. The current number of Makefile lines is close
to 12k. I think I can say with confidence that a complete
implementation in CMake would be smaller than this.
> I
> remember
> Michael commenting about problems defining macros (routines, ?) for
> CMake in a
> central place, he had to copy some things into every place that needed
> them
> (don't know if that's been fixed since).
All the problems I have encountered have been with cross-compiling.
Nothing insurmountable yet, but this part of CMake isn't as well tested.
> I'm not sure if he looked at
> building support modules, he doesn't seem to build the src/makeBaseApp
> directory at all.
No that is the next big task.
Regards,
Michael
- Replies:
- Re: configure/ reorganization Eric Norum
- References:
- src/ reorganization Davidsaver, Michael
- Re: configure/ reorganization Andrew Johnson
- Re: configure/ reorganization J. Lewis Muir
- Re: configure/ reorganization Andrew Johnson
- Navigate by Date:
- Prev:
Re: configure/ reorganization Andrew Johnson
- Next:
Re: configure/ reorganization Eric Norum
- Index:
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: configure/ reorganization Andrew Johnson
- Next:
Re: configure/ reorganization Eric Norum
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|