Am 20.12.2009 15:38, schrieb David Sugar: > I am often concerned about the idea of tools that independently produce > binary only rpm's because it then becomes easy for some to reject the > idea of producing full-cycle rpm's (or debs for those on the Debian > side) the way distros do to assure all binaries are legitimately built > from original sources, or at least it means these rpm's diverge from > those distro rpm's maintain downstream. However, yes, it is clearly > convenient for development, to do so directly out of a build, and I > gather it is at least possible to have it produce a src rpm as well.
To produce the binary RPMs and the source RPM as one make target is easy, we just need to define that in the cmake macro file. > > Traditionally the library versions (this started in debian, and suse > seems to follow this, it seems) carry an abi revision number as part of > the package name so that multiple incompatible abi's releases can be > installed at once in case an old binary requires an older abi, and each > can have independent updates (bugfixes). A non-abi versioned devel > package is used to assure both that the latest library version is used > for development, and because the include files of different purely abi > releases cannot co-exist without overwriting each other. I wasn't aware of that. Well, easy to fix :-) . > > I had wanted to reduce the extended library naming! Thanks! Actually, > this dates back to an era when c++ abi's were more unstable, and anyway > is, I think, far better handled in library package naming policies that > better separate incompatible abi releases than in extending the revision > naming of the .so. I want to do the same with ccrtp and commonc++. In > theory, from the perspective of downstream distros, if we do change this > up the stack, we really should release commonc++ and ccrtp changed this > way first. Sure. we can enhance the cmake files and the build process and then do a synchronized release. Regards, Werner > > Werner Dittmann wrote: >> All, >> >> I just committed a first working version of CMake files and cmake >> specific RPM spec file. >> >> These cmake files currently support: >> - building of libccrtp1 shared libs (no static lib yet) >> - creating a source distribution *.tar.gz >> - install and uninstall targets in the make file >> - building of binary RPM packages for runtime and development >> >> The w32, doc, and the phone stuff is not yet supported. >> The source RPM make target is enabled, but not yet fully tested. >> >> Inside the cmake specific spec file I made some modifications >> to align naming and remove inconsistencies, for example on my >> system (openSUSE 11.2) I see the following names: >> >> - libccrtp1 for the runtime package >> - libccrtp-devel for the development package >> >> I modified these to libccrtp1 and libccrtp1-devel >> >> As an additional modification during the compile, link and install >> process I changed the naming of the installable libs to better conform >> to the standard naming: >> >> libccrtp1.so -> libccrtp1.so.1.7 >> libccrtp1.so.1.7 -> libccrtp1.so.1.7.1 >> libccrtp1.so.1.7.1 >> >> The old naming scheme on my system is: >> /usr/lib64/libccrtp1-1.6.so.1 -> libccrtp1-1.6.so.1.0.1 >> /usr/lib64/libccrtp1-1.6.so.1.0.1 >> /usr/lib64/libccrtp1.so -> libccrtp1-1.6.so.1.0.1 >> >> Regards, >> Werner >> >> Am 19.12.2009 04:47, schrieb David Sugar: >>> I am in favor of supporting cmake, especially if we can do it alongside >>> the existing autotools. Yes, we need to do this down the stack, >>> including of course common c++ and there has already been one person >>> experimenting with commonc++ cmake. I also actually do want to use >>> cmake in ucommon and sipwitch as well. >>> >>> Werner Dittmann wrote: >>>> All, >>>> >>>> during the last days I created files and functions to support >>>> CMake based configuration setup. In a first step I did this >>>> for the ZRTP extension because I know this best :-) . The >>>> new CMake configuration cover the same functionality as >>>> autoconf, but much simpler to handle. This includes >>>> configuration, the full make targets and includes building >>>> a RPM package . These files are already available in SVN. >>>> >>>> I started to do the same for the ccRTP stuff. In my sandbox >>>> I have already a working setup that creates the ccRTP lib and >>>> creates a source distribution. Building a RPM package is the >>>> next step (quite easy), then adding the demo directory (also >>>> fairly easy). >>>> >>>> I did this exercise because some (well, at least kdevelop4) >>>> development tools do not support autoconf/automake anymore and >>>> switched to CMake. >>>> >>>> Both toolsets can live in parallel to simplify migration. >>>> >>>> Question: would it be ok if I checkin the cmake stuff for ccRTP >>>> also once I completed the above steps? Of course this is a first >>>> working version only that should be enhanced over the time. >>>> >>>> Regards, >>>> Werner >>>> >>>> >>>> _______________________________________________ >>>> Ccrtp-devel mailing list >>>> [email protected] >>>> http://lists.gnu.org/mailman/listinfo/ccrtp-devel >> _______________________________________________ Ccrtp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/ccrtp-devel
