Re: [Ccrtp-devel] CMake based configuration for ccRTP

[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.

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 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.

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
>>> address@hidden
>>> http://lists.gnu.org/mailman/listinfo/ccrtp-devel
>

dyfet.vcf
Description: Vcard