[Opencxx-users] Re: [opencxx] Porting to MacOs X

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

On Wed, 19 Feb 2003, Alexandre Tolmos wrote:

> Grzegorz,
>
> I merged Bruno's work with the current Cvs tree.

Great. (Isn't his name Michael Buro ?)

> The namespace problem
> is gone but I'm facing now another problem relating to dynamic libs:

Could you check in what you have before you move on to fixing
things with Darwin port? It would be better to have two checkins,
each covering a smaller change, than a big one with everything lumped
together.

I am attaching checkin instructions at the end of this e-mail. Should
you encouter any problems, let me know. Also send me you SF user id.

> "metaclass.h" includes some "ltdl.h" header file which does not exist
> on Mosx (well, Darwin actually).

This is file from libtool and it should be present in 'opencxx/libltdl/'.
Is it there?

> Is there a standard way to handle Dlls
> across multiple Unix variants (Posix?).

Yes. Libtool hides all the plarform specific stuff from you. I found
"darwin" in several places in libtool script, so it looks like this system
is handled.

> Moreover, Dlls have a ".dylib"
> extension on Darwin, not ".so" like on FreeBSD (although Darwin is Bsd
> based).

I also fount 'dylib' in libtool sources, so this should be covered too. If
you want to give an idea of how libtool works have a look at info docs
('info libtool') and Autobook (aka. Goat Book)  at
http://sources.redhat.com/autobook/ .

> Any help is welcome :)

Hope this helps.

Best regards
Grzegorz

--------------------------------------------------------------------
This is draft of something I am planning to put on the website soon.
Sorry for bugs etc., you should get the idea. Contact me
if any issues.

<html>
<body>

<h1>Comitting changes into CVS</h1>
<i>jakacki at users.sourceforge.net</i>

<ul>
<li> Contact project admin to discuss what you want to check in.

<li> Create your account on the SourceForge. Mail your user id to the
     project admin.

<li> Make sure you have the proper
     <href a=developer-tools-checklist.html>tools</a>.

<li> Read instructions
     about <href a=?>setting up CVS developers access</a>
     and <href=?>setting up SSH shell access</a> in Site Docs.

<li> Have a look at
     <a href=http://cvsbook.red-bean.com/cvsbook.html>CVSBook</a>.

<li> Set:

     export CVS_RSH
     CVS_RSH=ssh
     export CVSROOT
     CVSROOT=ext:<i>USERID</i>@cvs.sourceforge.net:/cvsroot/opencxx

<li> Once you are added to the project, create your sandbox
     (if admin hasn't do it for you) and check out the sources
     from your sandbox:

     cvs rtag -b sandbox_<i>SANDBOXNAME</i>

     for <i>SANDBOXNAME</i> take <i>USERID</i> (so the tag would be e.g.
     'sandbox_jakacki'), optionally followed by "_" and
     some text (e.g. 'sandbox_jakacki_refact')

<li> Check out your sandbox:

     cvs co -r sandbox_<i>SANDBOXNAME</i> opencxx

<li> Run

     cd opencxx
     ./configure --enable-maintainer-mode

<li> Introduce your changes. If you modify files controlling
     the build procedure (e.g. configure.in, Makefile.am etc.), run

     ./bootstrap

     You may also want to consult
     <a href=http://sources.redhat.com/autobook>Autobook</a>.

<li> Build

     make  # gmake on systems with non-GNU make

<li> Test

     cd testsuite
     make test    # or gmake

     You should get zero unexpected failures in tests summary.

<li> Commit

     cvs commit

     You comitted to your sandbox, not to the main trunk.
     When asked by cvs, leave the changes description empty.
     You will describe the changes when merging your sandbox
     into main trunk

<li> Log on to Compile Farm

     ssh cf.sourceforge.net

<li> Select the system you want to test on
     (from systems at CF we currently support
     PC/Linux, Sun/Linux, Sun/Solaris)

<li> Set up CVSROOT and CVS_RSH.

<li> Check out your sandbox:

     cvs co -r sandbox_<i>SANDBOXNAME</i> opencxx

<li> Build and test

     cd opencxx
     ./configure
     make          # or gmake
     cd testsuite
     make tests    # or gmake

     You should get zero unexpected failuers in tests summary.

<li> Log out from Compile Farm.

<li> Make your working copy a HEAD revision

     cvs update -A

<li> Merge your sandbox into the working copy of HEAD revision.
     Look out for CVS reports about conflicts.

     cvs update -j sandbox_<i>SANDBOXNAME</i>

<li> If somebody else did checkin while you were working in your
     sandbox, you may get conflicts during merge. In such a case:

     <ul>
     <li> Inspect the files in which conflits were reported and
          resolve the conflicts.

     <li> Go back to your sandbox with resolved conflicts

          cvs update -r sandbox_<i>SANDBOXNAME</i>

     <li> Test locally and on Compile Farm.

     <li> Try merging again.
     </ul>

<li> After you successfully merged your changes, you may want to review
     them:

     cvs diff

     and prepare short descriptions of what your changes do.

<li> Commit

     cvs commit

     supplying your descriptions. (Set EDITOR to your favorite editor
     if you are not satisfied with the one that CVS brings up.)

<li> Done.
</ul>
<br>

[I am working on a script that checkouts, configures, builds
and tests on Compile Farm, so the above is likely to get shorter. GJ]

</body>
</html>

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################