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
- Replies:
- Re: configure/ reorganization J. Lewis Muir
- RE: configure/ reorganization Jeff Hill
- References:
- src/ reorganization Davidsaver, Michael
- configure/ reorganization Andrew Johnson
- RE: configure/ reorganization Jeff Hill
- Navigate by Date:
- Prev:
[Bug 687435] [NEW] Callback subsystem behavior for muitlple callbacks Andrew Johnson
- Next:
Re: configure/ reorganization J. Lewis Muir
- 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 Jeff Hill
- Next:
Re: configure/ reorganization J. Lewis Muir
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|