> -----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
<2010>
2011
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
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|