Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

mcpp building suggestion

2008-04-22
2013-05-28
  • I'm trying to create a distribution package for mcpp (for Slackware), and am working on this because mcpp is pre-requisite for Ice (http://www.zeroc.com/), where mcpp is needed as static library.  However, I'd like to still make the package as general as possible, so I see no reason why it wouldn't be possible to build both stand-alone mcpp executable, and the libraries.  Seems to me that this is not the case now - if I select "--enable-mcpplib" option at configure phase, then libraries are compiled only, and not the executable.  It would make more sense to be able to have both built and included in a package for specific distributions - different users may need mcpp in different forms.

     
    • mef
      mef
      2008-04-22

      I'll second this -- I also need mcpp for Fedora, also because it's necessary for Ice. (I fully expect to see Debian/Ubuntu/SuSE packagers showing up shortly. :) )

      I managed to make a test package for Fedora including both the executable and the libraries by uncompressing the tarball twice into separate directories, calling ./configure separately in each of them, and then building them both. But that seems like a pretty nasty hack. :)

       
    • Hi mef, just noticed your comments over there at Ice forums when I was looking what's wrong after I hit same Ice issue as you did ("Assertion `_definitionContextStack.size() == 1' failed.") when trying to build Ice against stock mcpp 2.7.  Will second these as soon as I get my Ice forums registration approved, but here would like too to somewhat extend my previous suggestion for mcpp maintainer: Please do include patches from Ice people as soon as possible, and please do release 2.7.1 (or 2.8 or whatever you want to call it) version as soon as possible too - Ice project is giving lots of visibility to your project, and on the other side you'll probably want your project packaged for as many distributions as possible (because again it could provide it with lots of visibility), and the job will be much easier for everyone incorporated (especially for distributions packagers) if Ice builds against latest official mcpp build (it's important that you make a release with all latest issues fixed - it's hard to maintain a distribution package against a SVN revision), without any Ice private patches needed, and with all needed/available forms of mcpp (executable, static library, shared library) easy to build in single pass.

       
    • Kiyoshi Matsui
      Kiyoshi Matsui
      2008-04-22

      Thanks to you two for trying to make packages of mcpp!
      I have no time for a couple of days, sorry.  What is worse, I don't yet know anything about "ice".  So, I only inform you a few pointers in haste.

      1. Debian's "sid" (unstable) already has 4 packages of mcpp, libmcpp0, libmcpp-dev and mcpp-doc for 2.7-3 which were packaged by Yutaka Niibe and me, though I have not yet announced them on SourceForge.

          http://packages.debian.org/unstable/devel/mcpp

      The 4 packages are generated by single "rules" and single configure, and the mcpp executable links shared library of libmcpp.

      2. Revision 97 and 98 incorporated the patches of Debian's packages into configure.ac, Makefile.am, src/Makefile.am and internal.H.

      3. I want to release mcpp V.2.7.1 in the beginning of May.

      4. I'd like to hear from you any comments on the Debian's latest packages and revision 98, or any proposals on configure and packaging.

       
    • I provided URL (http://www.zeroc.com/) to examine about Ice above; also seems that these guys provided you with significant number of patches in the meantime (including latest freopen()->fopen() patch posted here: http://sourceforge.net/forum/forum.php?thread_id=2011291&forum_id=565342\), strange that you don't know that they're based on mcpp...

      I found pointers to Debian packages you posted useful, in order to learn about what are all files to be installed.  I don't know much about Debian packaging, so I was not able to find where is actual configure command line listed, that would make it possible to have both libraries and executable generated by single configure run, so I'd appreciate if you could post it here.  Also, if possible, I guess it would be very good to have some of these diffs, used for creating Debian packages, actually incorporated into mcpp.

      As for Slackware, it is actually much more easy-going than Debian (as I guess are most of other distributions): what is expected from an auto-tools based library/program to be packaged with Slackware is that it is able to install everything needed for using it through a single "./configure ... && make && make install" run, where "..." stands for configure options eventually needed (the best is if no specific options are needed, after all software developer should know better than packages, thus he should strive to select most meaningful options already set as defaults).  And that's all - so for mcpp, it would be enough if it could only install the program, libraries (including corresponding symlinks), the header file, and the documentation in alike single run.  Otherwise, seems like r98 would be good base for version 2.7.1; of course, it would be also very good if you could in the meantime include fix for configure script problem, that we discussed in the other thread, too.

       
    • Kiyoshi Matsui
      Kiyoshi Matsui
      2008-05-02

      Sorry for the delay of updating, I'm a little bit busy now.  I finally committed SVN revision 99, and fixed the bugs reported by Aleksandar, took the patches from Benoit and Dwayne.

      This revision (from revision 97) builds a library version of mcpp with --enable-mcpplib option for configure, and at the same time builds an mcpp executable which links shared library of libmcpp, and also installs a few documents.

      Slackware might make a package simply by 'configure --enable-mcpplib; make; make DESTDIR=... install'.

      Though the Debian's 2.7-3 packages patches configure, Makefile.am and src/Makefile.am, those patches are no longer necessary.

      As for Fedora, I uploaded a testing spec file and a tarball for the test at:

          http://kmatsui.fedorapeople.org/mcpp.html

      I devided the mcpp package into four packages (like Debian's 2.7-3 packages):
          mcpp        (executable)
          libmcpp     (shared library)
          libmcpp-devel   (headers to use library)
          mcpp-doc    (documents)

      These packages are generated from single spec file by a 'rpmbuild -ba mcpp.spec' command.

      How about these packaging specs?

      I will release mcpp V.2.7.1 in a few days, unless any problem is found.

       
    • As for Slackware - creating the package works fine, thanks for making changes!

      Could you possibly also add creating symlinks libmcpp.so.0 and libmcpp.so to libmcpp.so.0.2.0 to "make install" phase?

       
    • Kiyoshi Matsui
      Kiyoshi Matsui
      2008-05-04

      On my systems, symlinks libmcpp.so.0 and libmcpp.so to libmcpp.so.0.2.0 are created by 'make' after 'configure --enable-mcpplib' as:

      gcc -shared  .libs/main.o .libs/directive.o .libs/eval.o .libs/expand.o .libs/mbchar.o .libs/support.o .libs/system.o   -Wl,-soname -Wl,libmcpp.so.0 -o .libs/libmcpp.so.0.2.0
      (cd .libs && rm -f libmcpp.so.0 && ln -s libmcpp.so.0.2.0 libmcpp.so.0)
      (cd .libs && rm -f libmcpp.so && ln -s libmcpp.so.0.2.0 libmcpp.so)

      and 'sudo make install' installs them as:

      /usr/bin/install -c .libs/libmcpp.so.0.2.0 /usr/local/lib/libmcpp.so.0.2.0
      (cd /usr/local/lib && { ln -s -f libmcpp.so.0.2.0 libmcpp.so.0 || { rm -f libmcpp.so.0 && ln -s libmcpp.so.0.2.0 libmcpp.so.0; }; })
      (cd /usr/local/lib && { ln -s -f libmcpp.so.0.2.0 libmcpp.so || { rm -f libmcpp.so && ln -s libmcpp.so.0.2.0 libmcpp.so; }; })

      It is queer that Slackware fails to do it.
      I once experienced some confusion in installation of libmcpp, when I was doing trial and error of installation, and it worked well after I cleared wrongly installed libmcpp.

       
    • Yep, you are right - after un-installing previously installed mcpp package, all went fine with regard to creating shared library symlinks.

      I noticed another minor issue, though: it is not possible to build mcpp, with --enable-mccplib flag set during configure phase, with make -j n where n > 1.  Using -j flag of make is common these days, when most of us are running multi-core machines, but mcpp compilation fails because it seems that mcpp executable gets compiled faster than library, and then at its linking phase an error is reported because the library is not available.  So I guess in automake files, some kind of dependency should be established between the library and the program...

       
    • Kiyoshi Matsui
      Kiyoshi Matsui
      2008-05-05

      Thanks for the problem report!  I had not tested 'make -j n'.

      I did a trial and error to set an mcpp executable dependency on libmcpp, and found that an addition of the following line to src/Makefile.am works well.

      mcpp_DEPENDENCIES = libmcpp.la