[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Sharing individual files/subdirs between projects
From: |
William Dode |
Subject: |
Re: [Gnu-arch-users] Sharing individual files/subdirs between projects |
Date: |
Mon, 05 Jul 2004 13:52:08 +0200 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
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