Projects with shared libraries
All, I have some projects that share some libraries. Does CVS allow to have a common set of libraries that will be used by different projects?, in other words, I need one copy of these libraries and a reference to them in each of the other projects. Regards, Paola ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Projects with shared libraries
You could add the library to your product modules and build them all at once. However, I find that a better method is to subject the libraries to the same kind of control as the rest of the product (with regular builds, tagging sources, defect tracking and change control, etc.) and provide a set of well-known interfaces that can be used and tracked by the product builds. The references themselves should be versioned in some way, via source-controlled build scripts or environment settings, or by sampling the build environment and checking it in. A method that I've used with great success on many projects is the buildref method. You can find an implementation at the following URL: http://www.wakawaka.com/source.html --- Forwarded mail from [EMAIL PROTECTED] I have some projects that share some libraries. Does CVS allow to have a common set of libraries that will be used by different projects?, in other words, I need one copy of these libraries and a reference to them in each of the other projects. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Projects with shared libraries
Paul, I appreciate your answer, but I think I didn't explain my problem well. The projects I mentioned are independent from each other, and they share common libraries. I would like to have only one copy of these shared libraries, and a reference to them in each of my project modules. This way, I wouldn't have duplicated libraries' code in the projects that are sharing them. And when I upgrade the libraries (i.e. when a new release appears) I would have to do it only once. I'm not sure if CVS has this feature, I'm only asking if any of you has done this before or knows how to do it. Best Regards, Paola Paul Sander wrote: You could add the library to your product modules and build them all at once. However, I find that a better method is to subject the libraries to the same kind of control as the rest of the product (with regular builds, tagging sources, defect tracking and change control, etc.) and provide a set of well-known interfaces that can be used and tracked by the product builds. The references themselves should be versioned in some way, via source-controlled build scripts or environment settings, or by sampling the build environment and checking it in. A method that I've used with great success on many projects is the buildref method. You can find an implementation at the following URL: http://www.wakawaka.com/source.html --- Forwarded mail from [EMAIL PROTECTED] I have some projects that share some libraries. Does CVS allow to have a common set of libraries that will be used by different projects?, in other words, I need one copy of these libraries and a reference to them in each of the other projects. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Projects with shared libraries
I think it me who didn't communicate clearly! :-) The problem you describe appears to be a classic software reuse issue, in which you want to reduce the overhead to maintain some subset of your code that finds its way into many products. There are many ways to share code, each with their advantages and drawbacks. Methods include cutting and pasting lines of code in the source files, copying entire source files, building libraries and linking with them, build macros and templates, invoking executables, and many more that involve sharing artifacts not known by the build procedure per se (i.e. reusing various parts of the design and the code that follows from them). If I understand your specific issue correctly, you have some source code that you build into a library that links into several products. The library may be built and maintained on its own schedule, and the products upgrade their version of the library at their own convenience. The library builds are probably kept in well-known places with the expectation that product builds will use them. However, the reference and reproducibility requirements of the overall process have added complexity because the product builds must somehow track which versions of the library they use. The library's build procedure must be such that any version of the library must be reproducible, where the version is supplied as an argument from a product build. If you're building on Unix, then picking up the libraries at link time is a matter of setting the proper search paths and naming the desired libraries. This is usually done with options like -L and -R to set search paths, and -l to identify the libraries. It's easy to identify the names of the libraries to supply with -l options. The challenge is to set up the search paths. The reason for this is because the search paths themselves must be (or derive from) arguments passed to the product build, and the arguments must be stored and tracked for repeatability and reproducibility. There are a number of methods to store such arguments. One is to list the references in environment variables, and version control the script that sets them. Another is to compute them during a setup step and check them in. Yet another is the buildref method, which is a kind of publish-and- subscribe method where reference builds publish their interfaces and product builds refer to those interfaces (and remember which reference builds they used). Since you're at Oracle, you probably also have ClearCase at your disposal. Its wink-in (build avoidance) capability built into Clearmake offers yet another useful opportunity for reuse. >--- Forwarded mail from [EMAIL PROTECTED] >I appreciate your answer, but I think I didn't explain my problem well. >The projects I mentioned are independent from each other, and they share >common libraries. I would like to have only one copy of these shared >libraries, and a reference to them in each of my project modules. This >way, I wouldn't have duplicated libraries' code in the projects that are >sharing them. And when I upgrade the libraries (i.e. when a new release >appears) I would have to do it only once. >I'm not sure if CVS has this feature, I'm only asking if any of you has >done this before or knows how to do it. >Paul Sander wrote: >>You could add the library to your product modules and build them all at >>once. However, I find that a better method is to subject the libraries to >>the same kind of control as the rest of the product (with regular builds, >>tagging sources, defect tracking and change control, etc.) and provide a >>set of well-known interfaces that can be used and tracked by the product >>builds. The references themselves should be versioned in some way, >>via source-controlled build scripts or environment settings, or by sampling >>the build environment and checking it in. >> >>A method that I've used with great success on many projects is the buildref >>method. You can find an implementation at the following URL: >> >>http://www.wakawaka.com/source.html >> >>--- Forwarded mail from [EMAIL PROTECTED] >> >>I have some projects that share some libraries. Does CVS allow to have a >>common set of libraries that will be used by different projects?, >>in other words, I need one copy of these libraries and a reference to >>them in each of the other projects. >> >>--- End of forwarded message from [EMAIL PROTECTED] >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Projects with shared libraries
Paul, Thanks, your answer is clear but the problem is another. Let me explain, for example, I have 3 projects A, B and C. C is a set of generic libraries, same frameworks that A and B need. I'm using RedHat Linux as repository server with WinCVS clients. The clients "import" a CVS module A, or B and need C to work. I want A and B to reference C inside their modules. I'm not worried about build links. Is it possible to have "virtuals" folders and files inside A and B that "reference" C (in other words, "symbolic links" to physical files or folders to module C), and when developers IMPORT A or B, download the set of libraries referenced by these "virtuals" folders / files, and then they don't have to download module C, this is transparent for them. Best Regards, Paola Paul Sander wrote: I think it me who didn't communicate clearly! :-) The problem you describe appears to be a classic software reuse issue, in which you want to reduce the overhead to maintain some subset of your code that finds its way into many products. There are many ways to share code, each with their advantages and drawbacks. Methods include cutting and pasting lines of code in the source files, copying entire source files, building libraries and linking with them, build macros and templates, invoking executables, and many more that involve sharing artifacts not known by the build procedure per se (i.e. reusing various parts of the design and the code that follows from them). If I understand your specific issue correctly, you have some source code that you build into a library that links into several products. The library may be built and maintained on its own schedule, and the products upgrade their version of the library at their own convenience. The library builds are probably kept in well-known places with the expectation that product builds will use them. However, the reference and reproducibility requirements of the overall process have added complexity because the product builds must somehow track which versions of the library they use. The library's build procedure must be such that any version of the library must be reproducible, where the version is supplied as an argument from a product build. If you're building on Unix, then picking up the libraries at link time is a matter of setting the proper search paths and naming the desired libraries. This is usually done with options like -L and -R to set search paths, and -l to identify the libraries. It's easy to identify the names of the libraries to supply with -l options. The challenge is to set up the search paths. The reason for this is because the search paths themselves must be (or derive from) arguments passed to the product build, and the arguments must be stored and tracked for repeatability and reproducibility. There are a number of methods to store such arguments. One is to list the references in environment variables, and version control the script that sets them. Another is to compute them during a setup step and check them in. Yet another is the buildref method, which is a kind of publish-and- subscribe method where reference builds publish their interfaces and product builds refer to those interfaces (and remember which reference builds they used). Since you're at Oracle, you probably also have ClearCase at your disposal. Its wink-in (build avoidance) capability built into Clearmake offers yet another useful opportunity for reuse. --- Forwarded mail from [EMAIL PROTECTED] I appreciate your answer, but I think I didn't explain my problem well. The projects I mentioned are independent from each other, and they share common libraries. I would like to have only one copy of these shared libraries, and a reference to them in each of my project modules. This way, I wouldn't have duplicated libraries' code in the projects that are sharing them. And when I upgrade the libraries (i.e. when a new release appears) I would have to do it only once. I'm not sure if CVS has this feature, I'm only asking if any of you has done this before or knows how to do it. Paul Sander wrote: You could add the library to your product modules and build them all at once. However, I find that a better method is to subject the libraries to the same kind of control as the rest of the product (with regular builds, tagging sources, defect tracking and change control, etc.) and provide a set of well-known interfaces that can be used and tracked by the product builds. The references themselves should be versioned in some way, via source-controlled build scripts or environment settings, or by sampling the build environment and checking it in. A method that I've used with great success on many projects is the buildref method. You can find an implementation at the following URL: http://www.wakawaka.com/source.html --- Forwarded mail from [EMA
Re: Projects with shared libraries
Sorry, I have a mistake, please remplace import in the text for "working copy" Paola Attadio wrote: Paul, Thanks, your answer is clear but the problem is another. Let me explain, for example, I have 3 projects A, B and C. C is a set of generic libraries, same frameworks that A and B need. I'm using RedHat Linux as repository server with WinCVS clients. The clients "import" a CVS module A, or B and need C to work. I want A and B to reference C inside their modules. I'm not worried about build links. Is it possible to have "virtuals" folders and files inside A and B that "reference" C (in other words, "symbolic links" to physical files or folders to module C), and when developers IMPORT A or B, download the set of libraries referenced by these "virtuals" folders / files, and then they don't have to download module C, this is transparent for them. Best Regards, Paola Paul Sander wrote: I think it me who didn't communicate clearly! :-) The problem you describe appears to be a classic software reuse issue, in which you want to reduce the overhead to maintain some subset of your code that finds its way into many products. There are many ways to share code, each with their advantages and drawbacks. Methods include cutting and pasting lines of code in the source files, copying entire source files, building libraries and linking with them, build macros and templates, invoking executables, and many more that involve sharing artifacts not known by the build procedure per se (i.e. reusing various parts of the design and the code that follows from them). If I understand your specific issue correctly, you have some source code that you build into a library that links into several products. The library may be built and maintained on its own schedule, and the products upgrade their version of the library at their own convenience. The library builds are probably kept in well-known places with the expectation that product builds will use them. However, the reference and reproducibility requirements of the overall process have added complexity because the product builds must somehow track which versions of the library they use. The library's build procedure must be such that any version of the library must be reproducible, where the version is supplied as an argument from a product build. If you're building on Unix, then picking up the libraries at link time is a matter of setting the proper search paths and naming the desired libraries. This is usually done with options like -L and -R to set search paths, and -l to identify the libraries. It's easy to identify the names of the libraries to supply with -l options. The challenge is to set up the search paths. The reason for this is because the search paths themselves must be (or derive from) arguments passed to the product build, and the arguments must be stored and tracked for repeatability and reproducibility. There are a number of methods to store such arguments. One is to list the references in environment variables, and version control the script that sets them. Another is to compute them during a setup step and check them in. Yet another is the buildref method, which is a kind of publish-and- subscribe method where reference builds publish their interfaces and product builds refer to those interfaces (and remember which reference builds they used). Since you're at Oracle, you probably also have ClearCase at your disposal. Its wink-in (build avoidance) capability built into Clearmake offers yet another useful opportunity for reuse. --- Forwarded mail from [EMAIL PROTECTED] I appreciate your answer, but I think I didn't explain my problem well. The projects I mentioned are independent from each other, and they share common libraries. I would like to have only one copy of these shared libraries, and a reference to them in each of my project modules. This way, I wouldn't have duplicated libraries' code in the projects that are sharing them. And when I upgrade the libraries (i.e. when a new release appears) I would have to do it only once. I'm not sure if CVS has this feature, I'm only asking if any of you has done this before or knows how to do it. Paul Sander wrote: You could add the library to your product modules and build them all at once. However, I find that a better method is to subject the libraries to the same kind of control as the rest of the product (with regular builds, tagging sources, defect tracking and change control, etc.) and provide a set of well-known interfaces that can be used and tracked by the product builds. The references themselves should be versioned in some way, via source-controlled build scripts or environment settings, or by sampling the build environment and checking it in. A method that I've used with g
Re: Projects with shared libraries
You can embed (or include) module C inside modules A and B in the modules file so that when users populate their workspaces with modules A or B they also get C. There are a couple of ways to do this so that C is a subdirectory inside A and B, or it can be on its own outside of the A and B directories. Based on your latest description, I think this is what you want, assuming that C is self-contained in its own directory structure. If the files in C are interspersed with those of A and B in the same directories, then you're stuck; CVS can't combine files that way very well. It's theoretically possible to exhaustively list all of the appropriate files in the modules file, but it's a very inflexible mechanism when used in that way and unwanted things tend to appear during updates. If you're looking to have some kind of reference (e.g. symbolic link) created automatically in the user's workspace when fetching A or B, you're stuck. That's best done by the build procedure, and you need to have a copy of the correct version of C in a well-known place before the build starts. On Oct 22, 2004, at 6:48 AM, [EMAIL PROTECTED] wrote: Paul, Thanks, your answer is clear but the problem is another. Let me explain, for example, I have 3 projects A, B and C. C is a set of generic libraries, same frameworks that A and B need. I'm using RedHat Linux as repository server with WinCVS clients. The clients "import" a CVS module A, or B and need C to work. I want A and B to reference C inside their modules. I'm not worried about build links. Is it possible to have "virtuals" folders and files inside A and B that "reference" C (in other words, "symbolic links" to physical files or folders to module C), and when developers IMPORT A or B, download the set of libraries referenced by these "virtuals" folders / files, and then they don't have to download module C, this is transparent for them. Best Regards, Paola Paul Sander wrote: I think it me who didn't communicate clearly! :-) The problem you describe appears to be a classic software reuse issue, in which you want to reduce the overhead to maintain some subset of your code that finds its way into many products. There are many ways to share code, each with their advantages and drawbacks. Methods include cutting and pasting lines of code in the source files, copying entire source files, building libraries and linking with them, build macros and templates, invoking executables, and many more that involve sharing artifacts not known by the build procedure per se (i.e. reusing various parts of the design and the code that follows from them). If I understand your specific issue correctly, you have some source code that you build into a library that links into several products. The library may be built and maintained on its own schedule, and the products upgrade their version of the library at their own convenience. The library builds are probably kept in well-known places with the expectation that product builds will use them. However, the reference and reproducibility requirements of the overall process have added complexity because the product builds must somehow track which versions of the library they use. The library's build procedure must be such that any version of the library must be reproducible, where the version is supplied as an argument from a product build. If you're building on Unix, then picking up the libraries at link time is a matter of setting the proper search paths and naming the desired libraries. This is usually done with options like -L and -R to set search paths, and -l to identify the libraries. It's easy to identify the names of the libraries to supply with -l options. The challenge is to set up the search paths. The reason for this is because the search paths themselves must be (or derive from) arguments passed to the product build, and the arguments must be stored and tracked for repeatability and reproducibility. There are a number of methods to store such arguments. One is to list the references in environment variables, and version control the script that sets them. Another is to compute them during a setup step and check them in. Yet another is the buildref method, which is a kind of publish-and- subscribe method where reference builds publish their interfaces and product builds refer to those interfaces (and remember which reference builds they used). Since you're at Oracle, you probably also have ClearCase at your disposal. Its wink-in (build avoidance) capability built into Clearmake offers yet another useful opportunity for reuse. --- Forwarded mail from [EMAIL PROTECTED] I appreciate your answer, but I think I didn't explain my problem well. The projects I mentioned are independent from each other, and they share common libraries. I would like to have only one copy of these shared libraries, and a reference to them in each of my project modules. This way, I wouldn't have dup
Re: Projects with shared libraries
Great! Thanks! Best Regards, Paola Paul Sander wrote: You can embed (or include) module C inside modules A and B in the modules file so that when users populate their workspaces with modules A or B they also get C. There are a couple of ways to do this so that C is a subdirectory inside A and B, or it can be on its own outside of the A and B directories. Based on your latest description, I think this is what you want, assuming that C is self-contained in its own directory structure. If the files in C are interspersed with those of A and B in the same directories, then you're stuck; CVS can't combine files that way very well. It's theoretically possible to exhaustively list all of the appropriate files in the modules file, but it's a very inflexible mechanism when used in that way and unwanted things tend to appear during updates. If you're looking to have some kind of reference (e.g. symbolic link) created automatically in the user's workspace when fetching A or B, you're stuck. That's best done by the build procedure, and you need to have a copy of the correct version of C in a well-known place before the build starts. On Oct 22, 2004, at 6:48 AM, [EMAIL PROTECTED] wrote: Paul, Thanks, your answer is clear but the problem is another. Let me explain, for example, I have 3 projects A, B and C. C is a set of generic libraries, same frameworks that A and B need. I'm using RedHat Linux as repository server with WinCVS clients. The clients "import" a CVS module A, or B and need C to work. I want A and B to reference C inside their modules. I'm not worried about build links. Is it possible to have "virtuals" folders and files inside A and B that "reference" C (in other words, "symbolic links" to physical files or folders to module C), and when developers IMPORT A or B, download the set of libraries referenced by these "virtuals" folders / files, and then they don't have to download module C, this is transparent for them. Best Regards, Paola Paul Sander wrote: I think it me who didn't communicate clearly! :-) The problem you describe appears to be a classic software reuse issue, in which you want to reduce the overhead to maintain some subset of your code that finds its way into many products. There are many ways to share code, each with their advantages and drawbacks. Methods include cutting and pasting lines of code in the source files, copying entire source files, building libraries and linking with them, build macros and templates, invoking executables, and many more that involve sharing artifacts not known by the build procedure per se (i.e. reusing various parts of the design and the code that follows from them). If I understand your specific issue correctly, you have some source code that you build into a library that links into several products. The library may be built and maintained on its own schedule, and the products upgrade their version of the library at their own convenience. The library builds are probably kept in well-known places with the expectation that product builds will use them. However, the reference and reproducibility requirements of the overall process have added complexity because the product builds must somehow track which versions of the library they use. The library's build procedure must be such that any version of the library must be reproducible, where the version is supplied as an argument from a product build. If you're building on Unix, then picking up the libraries at link time is a matter of setting the proper search paths and naming the desired libraries. This is usually done with options like -L and -R to set search paths, and -l to identify the libraries. It's easy to identify the names of the libraries to supply with -l options. The challenge is to set up the search paths. The reason for this is because the search paths themselves must be (or derive from) arguments passed to the product build, and the arguments must be stored and tracked for repeatability and reproducibility. There are a number of methods to store such arguments. One is to list the references in environment variables, and version control the script that sets them. Another is to compute them during a setup step and check them in. Yet another is the buildref method, which is a kind of publish-and- subscribe method where reference builds publish their interfaces and product builds refer to those interfaces (and remember which reference builds they used). Since you're at Oracle, you probably also have ClearCase at your disposal. Its wink-in (build avoidance) capability built into Clearmake offers yet another useful opportunity for reuse. --- Forwarded mail from [EMAIL PROTECTED] I appreciate your answer, but I think I didn't explain my problem well. The projects I mentioned are independent from each other, and they share common libraries. I would like to have only one copy of these shared libraries, and a reference to them in each of m