[omniORB] Full COS compilation and cos.mk

[Duncan Grisby]

On Thursday 15 August, Alexy Khrabrov wrote:

> OK, seems like I found the line to uncomment in 
> src/services/mklib/cosinterfaces.mk in v4:
> _____
> # Uncomment this line to optimize the size of the COS library by only
> # including things required by omniNotify.
> 
> OPTIMIZE_OMNINOTIFY = 1
> ^^^^^
> uncommented in the snapshot tarball!

That's intentional. The main user of the COS library is omniNotify, so
it's optimised for that.

The issue with ir.idl is just a makefile problem. ir.idl _is_ compiled
during the omniORB build, but it has to be treated specially since it
puts declarations in the CORBA namespace. All that was needed was a
couple of declarations in the COS library makefile. It's fixed now.

[...]
> COS_INTERFACES = $(COS_ALL_INT)
> # ...
> 
> don't compile, as omni/idl/*.idl files, such as ir.idl, are not compiled
> while ir.hh is needed.  I manually compiled it and got a bit further, than
> got an error:
> 
> CosLicensingManagerSK.cc: In method `class CosLicensingManager::LicenseHandle * CosLicensingManager::_objref_ProducerSpecificLicenseService::start_use(const char *, const char *, CosPropertyService::_objref_PropertySet *, CosEventComm::_objref_PushConsumer *, CosLicensingManager::Challenge &)':
> CosLicensingManagerSK.cc:460: parse error before `)'

This is a bug in omniidl, due to ugly naming in CosLicensingManager.
It does something like

  module CosLicensingManager {
    struct Challenge { ... };
    interface ProducerSpecificLicenseService {
      ... start_use(... inout CosLicensingManager::Challenge Challenge);
    };
  };

i.e. it uses the same name for a parameter as the unqualified type
name. For reasons to do with compilers without namespace support, the
generated code cannot use the fully qualified name of the type, so it
ends up emitting code that uses Challenge for both the type name and
the parameter name, which upsets the C++ compiler. I've fixed the IDL
compiler to mangle the parameter name in this situation.

> Second, what is the use of cos.mk -- I don't see it included into any other
> .mk -- so if I do use COS services/libraries, where should I include cos.mk,
> i.e. perhaps at the beginning of dir.mk?

As Bob already said, you can include cos.mk in your dir.mk to get
rules that know how to use the COS library. If you write your own
simple make rules, there's no particular reason to use it.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --