You can embed (or include) module C inside modules A and B in the
modules file so that when users populate their workspaces with modules
A or B they also get C. There are a couple of ways to do this so that
C is a subdirectory inside A and B, or it can be on its own outside of
the A and B directories. Based on your latest description, I think
this is what you want, assuming that C is self-contained in its own
directory structure.
If the files in C are interspersed with those of A and B in the same
directories, then you're stuck; CVS can't combine files that way very
well. It's theoretically possible to exhaustively list all of the
appropriate files in the modules file, but it's a very inflexible
mechanism when used in that way and unwanted things tend to appear
during updates.
If you're looking to have some kind of reference (e.g. symbolic link)
created automatically in the user's workspace when fetching A or B,
you're stuck. That's best done by the build procedure, and you need to
have a copy of the correct version of C in a well-known place before
the build starts.
On Oct 22, 2004, at 6:48 AM, [EMAIL PROTECTED] wrote:
Paul,
Thanks, your answer is clear but the problem is another.
Let me explain, for example, I have 3 projects A, B and C. C is a set
of generic libraries, same frameworks that A and B need.
I'm using RedHat Linux as repository server with WinCVS clients. The
clients "import" a CVS module A, or B and need C to work. I want A and
B to reference C inside their modules. I'm not worried about build
links.
Is it possible to have "virtuals" folders and files inside A and B
that "reference" C (in other words, "symbolic links" to physical files
or folders to module C), and when developers IMPORT A or B, download
the set of libraries referenced by these "virtuals" folders / files,
and then they don't have to download module C, this is transparent for
them.
Best Regards,
Paola
Paul Sander wrote:
I think it me who didn't communicate clearly! :-)
The problem you describe appears to be a classic software reuse issue,
in which you want to reduce the overhead to maintain some subset of
your
code that finds its way into many products. There are many ways to
share code, each with their advantages and drawbacks. Methods include
cutting and pasting lines of code in the source files, copying entire
source files, building libraries and linking with them, build macros
and templates, invoking executables, and many more that involve sharing
artifacts not known by the build procedure per se (i.e. reusing various
parts of the design and the code that follows from them).
If I understand your specific issue correctly, you have some source
code
that you build into a library that links into several products. The
library may be built and maintained on its own schedule, and the
products
upgrade their version of the library at their own convenience. The
library
builds are probably kept in well-known places with the expectation that
product builds will use them. However, the reference and
reproducibility
requirements of the overall process have added complexity because the
product builds must somehow track which versions of the library they
use.
The library's build procedure must be such that any version of the
library
must be reproducible, where the version is supplied as an argument from
a product build.
If you're building on Unix, then picking up the libraries at link time
is a matter of setting the proper search paths and naming the desired
libraries. This is usually done with options like -L and -R to set
search paths, and -l to identify the libraries. It's easy to identify
the names of the libraries to supply with -l options. The challenge is
to set up the search paths. The reason for this is because the search
paths themselves must be (or derive from) arguments passed to the
product
build, and the arguments must be stored and tracked for repeatability
and
reproducibility.
There are a number of methods to store such arguments. One is to list
the
references in environment variables, and version control the script
that
sets them. Another is to compute them during a setup step and check
them
in. Yet another is the buildref method, which is a kind of
publish-and-
subscribe method where reference builds publish their interfaces and
product
builds refer to those interfaces (and remember which reference builds
they
used).
Since you're at Oracle, you probably also have ClearCase at your
disposal.
Its wink-in (build avoidance) capability built into Clearmake offers
yet
another useful opportunity for reuse.
--- Forwarded mail from [EMAIL PROTECTED]
I appreciate your answer, but I think I didn't explain my problem well.
The projects I mentioned are independent from each other, and they
share
common libraries. I would like to have only one copy of these shared
libraries, and a reference to them in each of my project modules. This
way, I wouldn't have dup
