ishapes and a bit on so files

[vermaete]

Hi,

First comit is needed to have the ishapes demo (second patch) working on a Raspberry Pi 4.

The second commit is to have 'ishapes' a packageconfig of the opendds recipe. What's new.

I probably will open an 'issue' about a strange behavior of 'ishapes' later this week.

br,

[mitza-oci]

Instead of patching the mwc file the strategy I typically recommend for this is to configure with --tests and then build just the targets that are needed, for example running make ishapes.

[vermaete]

@mitza-oci

Thanks for the review.

I'm not sure if first generating the makefile with configure in the do_configuration step of Yocto. And then not using the make all in the default do_compile step of Yocto. But instead do a kind of make all except the tests and then a make ishapes is a good Yocto practice. Unless I'm missed a kind of exclude-a-target flag of the make command.

And one of my next steps will be having the OpenDDS tests in the ptest framework of Yocto. What will make the bitbake recipe even more complicated if there is no patching done on the mwc file.

It looks like when going to the 4.0 release of OpenDDS with CMake it will be fixed anyhow.

Could we have his PR in the main/master for now?

[mitza-oci]

I'm not sure if first generating the makefile with configure in the do_configuration step of Yocto. And then not using the make all in the default do_compile step of Yocto. But instead do a kind of make all except the tests and then a make ishapes is a good Yocto practice. Unless I'm missed a kind of exclude-a-target flag of the make command.

Just from a system architecture / theoretical perspective, what's the point of having different "recipes" if each one must be exactly the same?

And one of my next steps will be having the OpenDDS tests in the ptest framework of Yocto. What will make the bitbake recipe even more complicated if there is no patching done on the mwc file.

I guess we can discuss in its own PR, but wouldn't that change mean using DDS_TAOv2_all.mwc anyway?

It looks like when going to the https://github.com/OpenDDS/OpenDDS/issues/4405 release of OpenDDS with CMake it will be fixed anyhow.

Even OpenDDS 3.x can now be built with CMake - with certain caveats.

Could we have his PR in the main/master for now?

Sorry it's taken some time to get back to this. I'll take a look before the end of the day today.

[mitza-oci]

I meant to add before...

Unless I'm missed a kind of exclude-a-target flag of the make command.

It's not an exclude-a-target, but it does have a way to build a certain target and all of its dependencies, which is the make ishapes example. The part that makes it more complicated is that I think you want to build the union of "all (or most?) targets that would be built with a --no-tests configure" and "ishapes and its dependencies". I think this is not something currently available in the MPC-generated makefiles, but it could be added.

Another approach would be to run something like mwc.pl -type gnuace examples/DCPS/ishapes after configure which will result in an independent makefile in the ishapes directory. Use the setenv.sh script for this like do_install:append:class-target().

[vermaete]

@mitza-oci

When is the 4.0 release expected? Or does it make sense to move in this meta layer of Yocto already to the cmake style? This would make the recipe of opendds much more common and less complex.

br

[mitza-oci]

When is the 4.0 release expected?

Please post a question in the OpenDDS repository. (I'm not trying to avoid answering, I actually don't have an answer.)

Or does it make sense to move in this meta layer of Yocto already to the cmake style?

You're certainly free to try. If you haven't yet done so I suggest reading the OpenDDS release notes that discuss what is and isn't supported in a CMake build.