RE: Extended feature

[Hageseter, Trond E.]

Well, the reason for this is that we have a organized our source so that
we have library code and core code separated. The library code was put
into a library tree where all code is shared by all developers on the
same computer. If development of a library took place, no other
developer would see the changes before the library was made official.
When a library was made official, all modified header files and the
library was copied into a common include and library directory.

ie.

/projects/common/src/mylibrary

when made official (build official), modified header files are copied to

/projects/common/include

and the library to

/projects/common/lib

Next time other developers compiles, he would "see" the changes and
because of dependencies recompile what was dependent on the modified
header files and finally link with the new library.

For core development, each developer have located under $HOME all core
functionality code. The main reason for this was to save disk space. If
every developer should also have his own version of the library tree, we
would run out of disk space at once. Remember, this is a project
initially started 6-7 years ago, when disk was not at all cheap. The
core code is changed mode often than library code. A library is almost
always only modified by one developer at a time.

A solution could be to make a new catalogue structure where libraries
and core shared a common root, but as long as the current approach with
separated library and core is working as today, I would rather not
change it. There are LOTS of makefiles and utilities that depend on the
existing structure I am afraid.

Good suggestions are welcome!

regards

trondeh

-----Original Message-----
From: Shigio Yamaguchi [mailto:address@hidden
Sent: 11. oktober 2001 12:32
To: Hageseter, Trond E.
Cc: Shigio Yamaguchi; address@hidden
Subject: Re: Extended feature


> When having multiple databases, the global -r option would not work
for
> the complete project as this only function for the "current" gtag'ed
> tree. In the example a gave, I could use the global -r command for the
> whole code, that in my case is split into two or more development
trees.

Why do you split your source tree which construct a project into some
trees?
--
Shigio Yamaguchi - Tama Communications Corporation
Mail: address@hidden, (Spare mail: address@hidden)