Re: Partial checkout builds

[Luke Shumaker]

I would suggest trying UnionFS (supported either natively, or via FUSE
on most *NIXen).  What you do is mount /release/src under /local/src,
with /local/src/ on top and /release/src on bottom.  UnionFS first
checks if a file exists on at the top layer, and keeps checking the next
layer until it finds the file, or goes through all the layers.

top:    /local/src:     util.h  m1.cc
bottom: /release/src:   util.h  m1.cc   m2.cc

Depending on which kernel you're on, you can either do the mount directly in 
/local/src,
or you may have to create a separate directory (as you do in Linux).

on Linux (via FUSE) the command to mount is:
unionfs-fuse -o cow /local/src/=RW:/release/src/=RO /build/src

on FreeBSD the command is:
Native:
mount -o union /release/src /local/src
FUSE:
mount_unionfs -o below /release/src /local/src

I hope this helps!

~ LukeShu

On Fri, 2010-10-22 at 11:54 +0100, Krzysztof Cieniuch wrote:
> Hi,
> What I'm trying to do is to make partial source tree  builds working.
> This is useful in release/patches scenario.
> When developing software time to time one needs to make release :-)
> After release development continues on head and released version is 
> tagged in source control system and is "frozen".
> Eventually it will be deployed in the field and then will come defect 
> reports (yes it has bugs :-)
> so one needs to prepare patches for that particular release version.
> One way to do that is to checkout tagged version fix issue rebuild 
> affected module (test) and ship to client.
> So if you need to prepare many patches/enhancements for the released 
> product one ends up with multiple checkouts of released version.
> The better solution would be to have released source checkout available 
> on network drive (with read only permissions) and be shared by all 
> developers.
> So when you need to patch module A you just checkout that module A (or 
> even better just files from that module that need to be modified)
> and setup your build environment so that any missing files in your local 
> checkout will be taken from common sources on network drive.
> 
> I got all bits and pieces working thanks to make and vpath the only 
> thing remaining is proper behavior of c/c++ preprocessor.
> 
> Here is example, let say we need to fix module A so after analysis it 
> turns out that one need to modify two files from that module so
> developer source tree looks like this:
> /local/src/modA/
>                              m1.cc
>                              util.h
> 
> And the release source tree on network drive:
> /release/src/modA/
>                              m1.cc
>                              m2.cc
>                              util.h
> /release/src/modB/
> ...
> 
> Note both m1.cc and m2.cc include util.h like this:
> #include "util.h"
> 
> Now if one modifies util.h make will correctly try to update  both m1.o 
> and m2.o (and then build library from those objects)
> m1.o will be build from correct files i.e.
> /local/src/mod1/m1.cc
> /local/src/mod1/util.h
> 
> but m2.o will be build form incorrect set of files:
> /release/src/mod1/m2.cc  <-- ok! : we do not have m2.cc checkout locally
> /release/src/mod1/util.h <-- problem! : preprocessor will first look in 
> current directory of m2.cc and will use release version of util.h 
> instead of our patched version
> 
> So it is strictly c/c++ preprocessor problem not make but since most of 
> the people on this list are using make to build something :-)
> maybe you have some ideas how to solve this issue.
> 
> I tried to employ  -I- option but that works fine only in simple 
> scenarios and one must be very strict how include files are included 
> (don't want to go into details here)
> so could be implemented if one have full control over sources but then 
> come system,  thirdparty headers that cannot be modified.
> Using  -I- option I ended up with huge list of  directories that need to 
> be included via -I option and header name clash problems.
> 
> Now I'm in the middle of implementing file io wrapper library that would 
> be preloaded when running compiler and would provide
> merged view of release and local directory to preprocessor (some poor 
> mans virtual file system) but I need to support three platforms Linux/Sun/Hp
> so it is not trivial and besides is not very portable (and it will be 
> very hard to verify correctness of that solution)
> 
> My question is is there  way  to fix that preprocessor issue or maybe 
> different approach that would make partial sources builds possible.
> 
> Thanks
> Chris
> 
> _______________________________________________
> Help-make mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-make