>> I'm not planning any changes to the 'build system' itself. I would >> hope, however, that things like shared libraries could be accommodated >> by using a different "config.*" file - e.g., perhaps named something >> like "config.linux-with-shared-libraries" or >> "config.debian-with-shared-libraries" - and then using the exiting >> "genMakefiles" tool. So that's the approach that I would pursue >> first. > > Adding shared library support requires adding an additional make target > that builds the additional .so files, because we want to keep the static > library. This cannot be done by just adding some variables to > config.linux-with-shared-libraries.
OK, fair enough. So here's what I'll do. If you send me a "config.linux-with-shared-libraries" file that uses the existing build system to build *just* shared libraries - even though that's not what you want - then I'll add it to the distribution. But I'll also use it to see if I can upgrade the build system (e.g., upgrade the "genMakefiles" tool and/or the "Makefile.head"/"Makefile.tail" files) to support a new "config.linux-with-static-and-shared-libraries" file that will build both static and shared libraries. >> (And as for the suggestion of switching to using 'CMake', see >> <http://lists.live555.com/pipermail/live-devel/2012-July/015600.html>) > > Thanks for the pointer. Can you point me to the latest proposed revision > of cmake config files? I don't think any such things exist, because - as far as I know - nobody is actually using CMake to build our code. Anyway, as I noted in my July email message, CMake is a non-starter, unless/until it can work with FreeBSD and also Windows with MS Visual Studio v5.0. >> (The only 'dynamic link' that I hope you put in Debian distributions >> is a 'link' to the URL "http://www.live555.com/liveMedia/";, so that >> people can download the latest version of the code; the only version >> that we support :-) > > The homepage field of the liblivemedia package points to > http://www.live555.com. Should I change it to point to the URL mentioned > above? Yes, please. >> But of course, you're welcome to try building shared libraries if you >> wish. > > I cannot do it properly without your help. Are you willing to maintain > one variable with the SONAME version. OK, I could do this. What would this variable look like (i.e., defined in a C/C++ source file)? Or do you mean that the variable would be defined in the Makefiles (rather than as a symbol in the library)? > # 3. If the library source code has changed at all since the last update, > then > # increment revision (`c:r:a' becomes `c:r+1:a'). > # 4. If any interfaces have been added, removed, or changed since the last > update, > # increment current, and set revision to 0. > # 5. If any interfaces have been added since the last public release, then > increment > # age. > # 6. If any interfaces have been removed since the last public release, then > set age > # to 0. These 'rules' seem very confusing, because the conditions that they describe can overlap. Example. If the current string is "c:r:a", and a new interface is added (but with no other changes), then does the new string become: - "c:r+1:a" (rule 3), or - "c+1:0:a" (rule 4), or - "c:r:a+1" (rule 5), or - "c+1:0:a+1" (rules 4 and 5) ??? It seems to me that the rules would be less confusing if, instead, they explained what happens in the following (non-overlapping!) situations: 1/ The code changes, but without any change to the API (i.e., interfaces). 2/ At least one interface changes, or is removed (i.e., so that existing code that uses the library would likely be incompatible with the new version). 3/ One or more interfaces were added, but no existing interfaces were changed or removed (i.e., so that existing code that uses the library might still remain compatible with the new version). Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
