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: src/ reorganization
From: "Davidsaver, Michael" <[email protected]>
To: "Andrew Johnson" <[email protected]>
Cc: [email protected]
Date: Thu, 16 Dec 2010 18:34:21 -0500

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Friday, December 10, 2010 5:11 PM
> 
> On Friday 10 December 2010 15:19:12 Davidsaver, Michael wrote:
...
> > It may be a
> > personal preference, but in the src/ directory at least I would
> rather
> > have a few large Makefiles.
> 
> I've just pushed a partial solution to LP which splits the
> libCom/Makefile
> into a series of Makefile and RULES fragments in the various source
> sub-
> directories.  See lp:~anj/epics-base/split-libCom-Makefile for the
> changes
> (which I will not merge without further discussion and agreement).  I
> suspect
> that you're not going to like it though because it uses include
> statements to
> pull those fragments into the libCom/Makefile.

Unless I'm missing something doesn't moving the extra rules before the
include of configure/RULES mean that 'all' will no longer be the default
target?  I tried a build and it seems to work, but I'm not quite sure
why.  I see that RULES_ARCHS and O.$(T_A)/Makefile use 'all' explicitly,
but don't see how the 'all' target from RULES_ARCHS gets invoked?

While I don't really like it.  Beyond this I can't see any technical
problems.

> Personally I think this
> makes
> it much easier to find the build instructions associated with a source
> file
> and vice versa.
> 
> If we used my approach with your structure, we could maybe end up with
> build
> directories (O.<target>) and "master" Makefiles in libCom, ioc, std
and
> template (like you I'm not sure about ca).  Each source sub-directory
> would
> still have a Makefile in it, and some would have RULES files as well.
> The
> disadvantage is that we would lose the ability to type 'make' in any
> source
> directory

Personally I don't see this as a serious disadvantage.

> and have it rebuild just the related libraries and products.

Your change has no effect on the target dependencies.




Replies:
Re: src/ reorganization Andrew Johnson
References:
src/ reorganization Davidsaver, Michael
Re: src/ reorganization Andrew Johnson
RE: src/ reorganization Davidsaver, Michael
Re: src/ reorganization Andrew Johnson

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