EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: configure/ reorganization
From: "Davidsaver, Michael" <[email protected]>
To: "Andrew Johnson" <[email protected]>, "J. Lewis Muir" <[email protected]>, <[email protected]>
Date: Wed, 8 Dec 2010 18:47:20 -0500

> -----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  <20102011  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  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·