My enviornment uses the clio DM system. When I go to create a new library, Cadence asks for the cds.lib to checkout. A lot of times the managed file is locked and I cannot edit it. For this reason I create a non-managed "cds_custom.lib" that I include in my "cds.lib". If I specify a filename that is not "cds.lib" in the"Check out cds.lib" form that comes up, it fails to edit anything and I cannot create a library.
Is this a DM bug or Cadence bug?
If it is a Cadence bug, it seems trivial enough to change to allow any file name to be modified, as in my example a user may need to modify a referenced library file in the same path as the cds.lib.
I think the probelm is the way the environment was set up. The cds.lib should be for the user and not shared by the group. Usually the environment is set up so that the cds.lib sources another file that is managed. For example, the users cds.lib (unmanaged) sources a project_cds.lib (managed) that contains the libraries used for the project you are working in. If a library needs to be updated for the group then the project_cds.lib is edited and checked in and everyone is updated next time they start the tool.
In reply to TeeBro:
The problem with that methodology is a user must then know to create a cds.lib and then add "INCLUDE project_cds.lib"
In my methodoly, the average user just starts cadence in that path and everything just works. If they want to add custom libraries, the create custom.lib and "INCLUDE custom.lib" is already in the cds.lib.
In reply to acook:
Even in a non-design managed environment, when you add a new library, you don't have the choice to add the library definition into an included cds.lib-like file; it adds it into the cds.lib (or whatever file is "forced" with ddSetForcedLib, or via -cdslib on the command line - although I'd advise against doing this because there are almost certainly assumptions in some parts of the tool that the file is called cds.lib).
So I'm not quite sure why you decided on your methodology.
I'm pretty certain that many DM systems recommend that you do it the way that Thomas suggested. Having a quick scan through the SOS documentation, it doesn't seem to suggest that - mainly because they support managing the cds.lib. Historically though I've always done it by managing a project.lib type file - and then manually moving the library into the project.lib when you want it managed.
Usually there is a script that sets up a users directory structure including adding a template cds.lib file that already has the included "project" cds.lib definition. From there the user only has to add/create a custom library if needed. If the whole group needs the library it can then be added to the "project" cds.lib and checked in for everyone to checkout.
OK, thanks guys. I'll do something like:
test -f cds.lib && echo "cds.lib exists" || echo "INCLUDE project.lib" > cds.lib
Back to my original comment though, why only allow a "cds.lib" file to be appended in the create library form?
Because that's the way it is and has been for the last 16 years or so... there's never been enough demand to change it (as far as I know). By all means contact customer support and request that though...