[p4] Auxiliary libraries

johan.nilsson at esrange.ssc.se johan.nilsson at esrange.ssc.se
Mon Dec 3 06:14:42 PST 2001


Sorry if I'm asking about obvious stuff, but see my comments inline.

> -----Original Message-----
> From: Stephen Vance [mailto:steve at vance.com]
> Sent: den 3 december 2001 14:43
> To: johan.nilsson at esrange.ssc.se; perforce-user at perforce.com
> Subject: Re: [p4] Auxiliary libraries
> 
> 
> My preferred approach is to create a vendor branch that 
> includes source 
> and/or libraries as delivered and necessary.

This is not a 'branch' as created by e.g. 'p4 integrate ...' I take it?
Rather, it is a 'subdirectory' of a depot like '//depot/vendor/roguewave' -
right?

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 guess that you check it in to the same location each time as you specify
below (and do you then label each release)? What're the actual steps you are
performing? How do you handle removed/added files? 

  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.
> 

So you're having some kind of //depot/vendor/binaries/ structure as well (do
you keep pre-build debug _and_ release binaries)? Having pre-built binaries
including debug information in the depot (and keeping each version) will
fill some disc space pretty quickly I guess?

> 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.

Ok, so what if I do several drops of e.g. 'SuperLib' like version 1.0, 1.2,
2.0 and originally performed a branch of the product when it was at version
1.0 to '//depot/myproj/SuperLib' and now realize that I'd like to use
version 1.2 of 'SuperLib' inside 'myproj'? Would I need to always label the
'drops' and use something like 'p4 integrate -b
branch_of_superlib_for_myproj -s @label_superlib_1.2' - am I on the right
track here?

// Johan

[snip]



More information about the perforce-user mailing list