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

[Werner Dittmann]

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