Re: [ccmtools-devel] ccmtools/environment

[Joerg F. <jf...@sa...>]

>>>>> "Leif" == Leif Johnson <le...@am...> writes:

>> The external/mico thing is a major pain in the ass. Google just told
>> me that there is a more sophisticated autoconf piece in the autoconf
>> macro archive
>> (http://www.gnu.org/software/ac-archive/htmldoc/ac_pkg_mico.html). As
>> Confix comes with that archive, it would be fairly easy to integrate
>> it. I'd give it a try over the weekend, if you want. AC_PKG_MICO
>> doesn't know of CCM however, but we're not using that anyway.
>> 
>> Having a confix module for mico would be a good example for how
>> external packages are glued into confix, so it's not a bad idea to put
>> it in the utils package.

Leif> So this is a utils package that's part of Confix, or a Salomon internal
Leif> package ? I'm a bit confused. Also, I'd like to clarify the separation
Leif> between the WX_Utils package and the CCM_Utils package ... which is
Leif> which ?

Ah, sorry. This is a Salomon module, and I suppose you've never seen
it. It's Makefile.py is

EXTERNAL_LIBRARY(
    enabled='no',
    defroot='/usr/local',
    incdir='include',
    libdir='lib',
    lib_bases=['micoccm2.3.10',
               'micocoss2.3.10',
               'mico2.3.10',
               # mico needs dlopen() and friends
               'dl'],
    provide=['CORBA.h'],
    featuremacros=['HAVE_MICO']
    )

It doesn't have any shell code to determine the more detailed
properties of the Mico installation, but rather has the libraries and
their version numbers hardcoded. Pain.

What you need in your remote C++ environment is a way to tell Confix
that it should link in the Mico libraries where needed (that is, when
<CORBA.h> is seen in a source file). Egon was thinking of using the
external/mico module above. My suggestion was to add a module to your
environment instead that has the necessary glue code (using
AC_PKG_MICO) that I posted.

Joerg