Best Practice: SDK Locations in Source Tree; Xlinks

[wyattetal]

Can anyone comment on the pros and cons of placing large SDKs, such as a fully built Boost, at the deepest level of an xlink'ed source hierarchy?

 

Taking boost as a concrete example, imagine the following:

BoostSDK is stored in a repository.

Code Modules A, B and C are also each stored in a repository.

Each of A, B and C have an xlink to BoostSDK.

 

When a workspace for A (or B or C for that matter) is created on a development PC, the xlink instantiates BoostSDK within the workspace folder for A. A thus "owns" its own BoostSDK instance, and this can be very useful since A can now dictate which branch (version) of Boost it prefers to utilize. One obvious cost for this specificity is of course disk space.

 

Along comes a new project - lets call it FOO - that in turn xlinks to all of A, B and C. By XLinking to A, B and C, a workspace for FOO now contains three instances of BoostSDK - one within each of A, B and C.

 

Is Xlink not a recommended solution in such "large SDK cases", and best used for encapsulating ever smaller and unique development code modules rather than large general SDKs? Just because xlinks CAN be used to construct an associative tree of repos, are there reasons and/or experience that reveals why they should NOT be used in this way? 

What are some well worn strategies for positioning large SDKs within a collection of plastic repos so that those SDKs can be used most efficiently?

 

Thanks in advance!

 

 

[manu]

Hello!

 

I don't' foresee any issue other than the disk space. Although it's not a problem at all with interdependent projects it will be while dealing with multiple projects at the same time.... You'll have the same SDK multiplied several times.

It will also be a problem as you pointed while dealing with a project xlinking several subprojects xlinking at the same time their SDKs.

I think I rather prefer to have an extra workspace working with the SDK repo and set the project to use the local path to the SDK workspace. Then, if you have more projects you can reuse a set the project to use the SDK workspace, if you need any other SDK then you'll need to create another wks.

 

If disk space is not a problem for you then use xlinks, no problem at all.

 

If disk space is a problem and you still get the benefit of using xlinks (contributing with changes to the SDK for example or better release management...) then you can even, for the super "FOO" project, xlink a branch of the A, B and C projects where the xlinks are removed. That will save you loading the same SDK multiple times. It's similar than reusing the same game engine for multiple games, where each game xlinks a different game engine branch: