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: "Jeff Hill" <[email protected]>
To: "'Andrew Johnson'" <[email protected]>
Cc: [email protected]
Date: Wed, 8 Dec 2010 14:33:52 -0700
> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> On Tuesday 07 December 2010 18:23:14 Jeff Hill wrote:
> > > I have thought about something like that in the past, but I wasn't
sure
> > > where we'd put the files for cross-compiling where host os != target
> os.
> >
> > Perhaps when, os != target os, then target os files would go in a
> > subdirectory of the host. Like this.
> >
> > configure/os/linux/             <= linux host build
> > configure/os/linux/vxWorks      <= linux cross build for vxWorks
> 
> Don't like:
>  * The tree gets too deep and sparse

It just might be a bad design to end up with a sparsely populated directory
tree. I don?t claim to have looked at the situation in detail recently
(since R3.13), but on the surface it appears that there is room for some
improvement in terms of taking hierarchy out of the file names and moving it
to the file path.

>  * Comparing and grepping for things becomes a pain

Personally, I use the find-in-files dialog in the IDE - which instantly
searches all of base, at all levels. Once I have a list of matches in the
gui, I just click on them to pop the editor at the relevant line.

>  * Hard to implement
> I suspect
> would lose out on the orthogonality of the current system (settings can be
> overridden at many levels, and are in different files for different
> targets).

I think it's safe to say that the build system can find the relevant file
either by hierarchy in the file name or hierarchy in the file path,
whichever of these choices we decide to prefer. No doubt change in this area
would require some work. Most important would be proper levels of design
work up front, but certainly eventually some implementation work like
internally cracking T_A into two variables or whatever is required, but
maybe once we know what to do implementation can be easy.

Also not opposed to looking at the viability of using someone else's build
system.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925


> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> On Tuesday 07 December 2010 18:23:14 Jeff Hill wrote:
> > > I have thought about something like that in the past, but I wasn't
sure
> > > where we'd put the files for cross-compiling where host os != target
> os.
> >
> > Perhaps when, os != target os, then target os files would go in a
> > subdirectory of the host. Like this.
> >
> > configure/os/linux/             <= linux host build
> > configure/os/linux/vxWorks      <= linux cross build for vxWorks
> 
> Don't like:
>  * The tree gets too deep and sparse
>  * Comparing and grepping for things becomes a pain
>  * Hard to implement
> 
> It doesn't make sense that a self-hosting architecture uses just one level
> but
> a cross-build for the same OS uses a second level.  Case in point, linux-
> arm
> can self-build or be cross-built on linux-x86, but many of the values are
> going to be the same for both.
> 
> When GNUmake is executing, if it's set T_A contains both the OS and CPU,
so
> it
> doesn't match your structure above.  The configure/CONFIG file currently
> finds
> the OS_CLASS by including $(CONFIG)/os/CONFIG.Common.$(T_A) which is
> required
> to set it.  With your structure we either wouldn't know the path to the
> file,
> or we'd have some files in one place and some in another.  I wouldn't
> suggest
> trying to use the target-arch as the dir-name, because of all the -debug
> and
> related targets that really belong with the base architecture.
> 
> > The issue is reasonably fast access. It gets a bit painful sometimes
> > sifting through 162 files when you are looking for how its configured
and
> > you may not remember exactly what is in CONFIG.linux-x86.linux-x86
versus
> > what is in CONFIG.Common.linux-x86. These two files are not close to
each
> > other in a file open dialog.
> 
> I agree that managing a directory with 244 files in it is a pain, but I
> think
> any major overhaul is going to take many trial implementations and I
> suspect
> would lose out on the orthogonality of the current system (settings can be
> overridden at many levels, and are in different files for different
> targets).
> Janet is not going to have the time to develop any major changes.
> 
> 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).
> 
> - Andrew
> --
> If a man is offered a fact which goes against his instincts, he will
> scrutinize it closely, and unless the evidence is overwhelming, he will
> refuse to believe it.  If, on the other hand, he is offered something
> which affords a reason for acting in accordance to his instincts, he
> will accept it even on the slightest evidence.  -- Bertrand Russell



References:
src/ reorganization Davidsaver, Michael
configure/ reorganization Andrew Johnson
RE: configure/ reorganization Jeff Hill
Re: configure/ reorganization Andrew Johnson

Navigate by Date:
Prev: Re: configure/ reorganization J. Lewis Muir
Next: Re: configure/ reorganization Andrew Johnson
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 Stephen Lewis
Next: RE: src/ reorganization Davidsaver, Michael
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 ·