17 messages in com.perforce.perforce-user[p4] Branching whole projects vs. sub...| From | Sent On | Attachments |
|---|---|---|
| Noel Llopis | 24 Dec 2003 04:29 | |
| Noel Yap | 24 Dec 2003 04:50 | |
| Oren Shemesh | 24 Dec 2003 05:15 | |
| jab | 24 Dec 2003 07:03 | |
| Noel Llopis | 24 Dec 2003 10:51 | |
| Noel Yap | 24 Dec 2003 12:37 | |
| Chuck Karish | 24 Dec 2003 13:16 | |
| Noel Llopis | 24 Dec 2003 13:27 | |
| Noel Yap | 24 Dec 2003 13:36 | |
| Noel Yap | 24 Dec 2003 13:51 | |
| Chuck Karish | 26 Dec 2003 08:24 | |
| Arnt Gulbrandsen | 30 Dec 2003 02:48 | |
| Alen Ladavac | 30 Dec 2003 03:22 | |
| Grills, Jeff | 30 Dec 2003 16:48 | |
| Stephen Ng | 31 Dec 2003 05:18 |  .py |
| jab | 31 Dec 2003 06:46 | |
| Stephen Ng | 31 Dec 2003 09:55 |
| Subject: | [p4] Branching whole projects vs. sub-sections |
|---|---|
| From: | Chuck Karish (kar...@well.com) |
| Date: | 12/26/2003 08:24:35 AM |
| List: | com.perforce.perforce-user |
Chuck Karish wrote:
Noel Llopis wrote:
However, we might be switching a more traditional way of arranging our libraries and includes (it's a C++ project), and libraries might include header files from other libraries directly from their directory by using relative paths.
The Makefiles can be arranged so that every header is referenced like this:
#include <library_a/header1.h>
for any number of libraries, with no particular burden on the programmers.
I don't accept that it's necessary to allow the use of relative paths for headers to avoid name collisions within the same library. That's why there's a directory name in the example given above. If it's necessary to use a relative path that points into another library's source tree, the API is not defined properly.
If you want to make your makefiles simple, you can arrange the headers like this:
project_name/include/library_a/ project_name/include/library_b project_name/include/library_c/
and so on. Each developer can have a second client in which to sync the stable versions of the other libraries, and each makefile needs one -I flag with a hard-coded relative path to the include directory for the library being worked on and one -I flag for the path to the include directory with all the stable versions of the headers.
This works best if the active client specification maps only the include directory and the source directory for the current library:
//depot/project_name/include/library_a/... //depot/project_name/library_a/...
and the client map for the stable headers excludes the headers for the library being worked on:
-//depot/project_name/include/library_a/... //depot/project_name/include/library_b/... //depot/project_name/include/library_c/...
Another way to manage the stable versions of the headers is to use internal releases, and to have everyone who's working toward a particular external release access the stable versions of the headers through a disk share. The compiled versions of the libraries not being worked on can be shared through the same mechanism.