Re: [Gnu-arch-users] Sharing individual files/subdirs between projects

[William Dode]

Mikhael Goikhman <address@hidden> writes:

> On 05 Jul 2004 09:09:39 +0200, William Dode wrote:
>> 
>> Mikhael Goikhman <address@hidden> writes:
>> 
>> > archzoom tree looks like:
>> >
>> >     README
>> >     bin/archzoom.cgi
>> >     bin/axp               # shared with axp
>> >     perllib/Arch/         # shared with arch-perllib
>> >     perllib/ArchZoom/
>> >     perllib/AXP/          # shared with axp     
>> >     tests/
>> >
>> > There is no requirement for the marked share points to be modifiable.
>> >
>> > I see 8 roads toward these requirements.
>> >
>> > 1) Fork each project from another and delete/add files, then use merging.
>> > This seems to be too problematic to even try, since there are more
>> > unshared files/subdirs than shared ones.
>> >
>> > 2) Create new smaller projects, one per share point. Not an option.
>> >
>> > 3) Nest projects (using configs). However this seems to be pretty
>> > problematic with these requirements.
>> 
>> Why it's problematic ?
>
> I would like to have trees like mentioned in the requirements. This is
> important to simplify 1) hacking, 2) installation process, 3) releases.
>
> Becides, I see no reason to nest the whole tree of another project that
> contains a lot of irrelevant files used for testing, separate installation
> (scripts, autoconf stuff), documentation and examples.

I didn't thought about that, but don't forget that a buid-config --link
is very cheap.

I do this :

arch.config = external/lib1 ...
              external/lib2 ...
 
external/lib1/README
              mylib1/
              ...
         lib2/...
              mylib2/
              ...


lib/mylib1 (a link with external/lib1/mylib1)
   /mylib2    "             "

...
...


>
>> > 4) Don't nest, but require these projects to be checked out in the same
>> > directory level (possibly using the forth project and configs), then use
>> > out-of-project symlinks to define share points. Works on unix.
>> >
>> > 5) Keep only one united super-project in arch, with distinct file names.
>> > This is what I do now.
>> >
>> > 6) Just "cp -a" from one project to another from time to time.
>> >
>> > 7) Hack a system smarter than "cp -a", to duplicate the structure of
>> > matched changesets (with constraints) from the master project to the
>> > secondary project, and possibly vice versa too. Still no arch involved
>> > in this system (no merging) that makes it difficult for me and others.
>> 
>> 6) and 7) seems exactly what configs do if you add an arch.config in the
>> archzoom project (you don't need to create an other project for this).
>
> Please elaborate. How do you suggest arch.config to look to implement
> copying of individual files/subdirs?

No idea for that :-(

-- 
William Dodé - http://flibuste.net