[p4] Auxiliary libraries
steve at vance.com
Mon Dec 3 05:42:40 PST 2001
My preferred approach is to create a vendor branch that includes source
and/or libraries as delivered and necessary. I then integrate this branch
into the source trees (projects, products, etc.) that require it. For
example, with RogueWave which is delivered as source, I check in the source
then do a build on the source and check in the resulting binaries
(libraries, linkage files, even build logs to capture the options used as a
backup). I keep the binaries separate from the source so that I can simply
integrate the binaries, rather than inflicting the source on all
projects. You could integrate the source if you wanted your developers to
be able to debug into the library.
When you get your next version, just create a client with the "allwrite"
option set, unpack the libraries, and use the techniques from Tech Note #2
to figure out what changed. Once you've assessed the impact, done your
builds, etc. you can integrate the new version out to products and projects
as they are ready to take on the porting and compatibility issues. You
can't really do this latter part very easily if everyone is sharing the
original drop branch. That's the main reason I prefer this approach over
the "map the drop branch into each client" approach.
At 11:12 AM 12/3/2001 +0100, johan.nilsson at esrange.ssc.se wrote:
>is there any general approach preferred among the Perforce users (or for CM
>in general) for managing dependencies to external libraries such as Boost
>C++ or STLport? Do you usually add the library to your depot, and create a
>project-specific branch when needed? How do you handle updates and
>integrations? Which files do you include (source, help, pre-built binaries)?
>I'd be grateful for any real-world experiences and policies for how do
>actually implement this.
>Thanks // Johan
>perforce-user mailing list - perforce-user at perforce.com
mailto:steve at vance.com
More information about the perforce-user