Re: Trying to create OpenDDS recipe

[Darren Hart <dvhart@linux.intel.com>]

Nitin, Khem, some toolchain related (I think) questions inline below.

On 07/28/2011 04:16 PM, Ourada, Paul wrote:
> Hi Darren -
> 
> Thanks for getting back to me. I have been able to get a lot further
> with the recipe. It turns out that the problem is in the makefiles
> for OpenDDS. I'll detail further below.
> 
> Paul E. Ourada Sr. Principal Software Engineer Covidien, Energy-based
> Devices 5920 Longbow Drive Boulder, CO 80301 
> paul.ourada@covidien.com www.covidien.com Main: 303-530-2300 Ofc:
> 303-581-6940 Fax: 303-581-6741
> 
> 
>> Hi Paul,
> 
> On 07/19/2011 07:41 AM, Ourada, Paul wrote:
>>> I hope this is the correct place to post this. If not, please let
>>> me know.
> 
>> This is the right place. In the future please don't reply to an
>> existing post as your message then gets threaded with the one you
>> replied to (likely why you didn't receive a response so far - that
>> I see anyway).
> 
> I guess I thought that changing the subject would have fixed that.
> Guess the mail list s/w is smarter than that. :)

In case you're actually curious :-) it's your mail client. It inserts
the following header:

In-Reply-To: <E7D51FCF-F5DC-448D-8354-410E0217D10F@kernel.crashing.org>

Which a compliant mail reader will thread with that message.

> 
>>> 
>>> I'm trying to create a recipe for OpenDDS. The recipe works so
>>> far as fetching, unpacking, and configuration. Or it seems to. :)
>>> Part of the configuration piece is that it also pulls down
>>> ACE+TAO real-time CORBA. This part works fine as well.
>>> 
>>> I set S as follows to match the unpacking directories enforced by
>>> the tar file:
>>> 
>>> S = ${WORKINGDIR}/DDS
>>> 
>>> The package comes with a configuration script pre-built, and it
>>> expects to be told where glibc is. So, I write do_configure as
>>> follows:
>>> 
>>> EXTRA_OECONF = "-glibc=${STAGING_DIR}/${MACHINE}/usr"
>>> 
>>> do_configure() { ${S}/configure ${EXTRA_OECONF} }
>>> 
>>> The problem that I run into is during compilation. I write the
>>> following for do_compile()
>>> 
>>> do_compile() { oenote ${STAGING_DIR} cd ${S} && make }
> 
>> Is there a reason you are overriding configure and compile? These
>> appear to be autoconf projects, which should just work for recipes
>> using autotools.bbclass.
> 
> I had tried that initially. The configuration file is already
> supplied, so running autotools to create the configure script is not
> necessary, but running ./configure is. Is there a better way to do
> that?

Does regenerating .configure actually cause a problem? If not, I would
still suggest using the autotools base and simplify your recipe.

> 
> : : << most of the compiler command line gobblety-gook snipped>>
> 
>>> -DTAO_IDL_PREPROCESSOR=\"i586-poky-linux-g++ -march=i586
>>> --sysroot=/opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86\"
> 
> 
>>> The thing that is puzzling me is that --sysroot seems to be
>>> pointing in the general direction of ${STAGING_DIR} and so the
>>> include directive, #include <features.h>> should be good. I have
>>> checked, and features.h is in the /usr/include subdirectory
>>> there.
> 
>> I see unistd.h missing, not features.h.
> 
> You're right, it was complaining about unistd.h, but it turns out
> that the real culprit was the TAO_IDL_PREPROCESSOR macro above. When
> I compared it to what was being emitted in the Ubuntu compile, I saw
> that the long, nasty, compound, double-quoted thing should have just
> been "i586-poky-linux-g++." TAO_ID_PREPROCESSOR was being assigned
> the value of ${CXX}.
> 
> It appears that instead of pre-pending the ${CPPFLAGS} variable,
> yocto/poky recipes were appending the cross-compile build variables
> to ${CXX}. I patched the OpenDDS makefile(s) to look for the first
> word in the ${CXX} macro, and substituted that in the assignment of
> TAO_IDL_PREPROCESSOR. Dunno if that's the "right" way to do it, or if
> there's a bug in ${CXX} assignment?

These are good toolchain questions for Nitin or Khem, now on CC.

> 
> Anyway, I think that I'm getting there w/the recipe. I'm sure that
> there are some things I'm doing wrong. For instance, I'm no longer
> cd'ing to ${S}, as OE already takes me there. I'm also using
> oe_runmake in do_compile().

If you're running oe_runmake from do_compile then you might be able to
omit do_compile and use the base class implementation.

> 
> I expect that I'll be running some version of "make install" at some
> point.

Again, should be automagic.

> 
> I'm sure I'll have more questions as I go along.
> 
> Thanks for helping an OE/Yocto N00b!
> 
> Paul
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel