Adef files & c++


#1

Hiya,

This is for those trying to use C++ in the Legato environment.

I’ve just found that the adef parser doesn’t like C++ files (i.e. files with the extensions .cc or .cpp) when configuring the project executables. This was a problem for me as the application I’m porting across to the Legato is based around a C++ class that contains all the application logic.

I did find a workaround:

I turned my application into a static library (using a separate DS3 project - note the bug in DS3 that doesn’t let you create a 'static library project - create a normal C++ project then change the Target type after creation). I also removed the code for ‘main()’ from my library.

Inside my library, I wrote a ‘factory’ function to instantiate my class and return a void pointer to it. I also wrote wrapper functions for the class public member functions so that they could be called from C. Finally, I wrapped the appropriate functions in 'extern “C” {} ’ so that the names wouldn’t be mangled by the compilers and linker.

I then turned main() into the Legato ‘main()’ - using COMPONENT_INIT { } and referencing my application class via the wrapper functions in the library.

Finally, I added both my static library AND the yocto stdlib++ static library to my adef definitions like so:executables: MyApp ( "legato_main.c" "libMyAppLib.a" "/opt/swi/y14-ext/tmp/sysroots/swi-mdm9x15/usr/lib/libm.a" "/opt/swi/y14-ext/tmp/sysroots/swi-mdm9x15/usr/lib/libstdc++.a" "/opt/swi/y14-ext/tmp/sysroots/swi-mdm9x15/usr/lib/libz.a" )

and all is sweet :smiley:

Note that I had to use the full path to the cross-compiler system libs … the adef parser can’t find them otherwise.

ciao, Dave


#2

Mmmm, I guess that we should:
[ul]
[li] As a minimum, provide an environment variable (or any other convenient way) to allow pointing on the toolchain provided libs in the adef[/li]
[li] Provide a way to toggle on C++ support in the adef (and Component.cdef) files (automatically as soon as a C++ source file is included in the list?)[/li][/ul]


#3

Hi daav,

[quote=“daav”]
[ul]
[li] As a minimum, provide an environment variable (or any other convenient way) to allow pointing on the toolchain provided libs in the adef[/li]
[li] Provide a way to toggle on C++ support in the adef (and Component.cdef) files (automatically as soon as a C++ source file is included in the list?)[/li][/ul][/quote]

Adding both of these would be a good idea. Building an environment variable at runtime sure beats hardcoding paths!

For me, getting C++ support in the adef files is probably slightly more important/useful than the environment variable (I can live with the hardcoded paths).

ciao, Dave


#4

Out of curisoity, what revision of C++ are you using? Are you using C++11?

One of the things we’re thinking of doing is adding a C++11 compatablity header to add support for creating C++ objects using memory pools and enable use of lambdas as callbacks. Among other things.

I don’t have a timeline on this, but since you are already using C++ some real world info would be really helpful.

Thanks,
-Kelly


#5

Hi, David,

Thanks for pushing the envelope and trying new things. We plan to do C++ support, but haven’t got around to it yet. (So much to do!) Your input on this is a big help.

The ‘mk’ tools (mkexe, mkapp) detect the source code language based on the file name extension. That’s missing the checks for the various C++ file name extensions.

I think we should be able to fix this fairly easily. We’ll look into it.

Thanks again!

–Jen


#6

Hiya,

Thanks all for the info and thoughts.

We’re not using any of the fancy bits of C++ - just using it to provide enforced object orientation and encapulation of data where it is required - mostly around protocol state machine handling and I/O devices.

Whoa! Way over my head here! I’m a hardware engineer that programs - not a programmer that does hardware… although I guess I need to learn some more.

[quote=“kmurphy”]I don’t have a timeline on this, but since you are already using C++ some real world info would be really helpful.[/quote]No probs. As we find things I’ll keep feeding them up to the forum.

It’s exciting to be working on this stuff - I like to push it hard and It’s nice that you guys are so responsive when I hit a wall. There’s always plenty to do …

Sounds like an easy fix. Well, easy to talk about anyway.

Cool. If you want any more info, let me know.

ciao, Dave


#7

Hello David,

Jen and I took a look at this. Like Jen said, the mktools were rejecting the C++ because of it’s extension.

I’ve also modified the tools to automaticly pull in the C++ standard lib. And I added some extern “C” definitions to the header files. So the result of this is that it will be easer to use C++ in Legato, for example, yet another hello world, but now in C++:

“helloPP.adef”

executables:
    hello ( hello.cpp )

processes:
    run: (hello)

“hello.cpp”

#include "legato.h"
#include <sstream>

COMPONENT_INIT
{
    std::stringstream buffer;

    buffer << "Hello world, #" << 1024 << ".";
    LE_INFO("%s", buffer.str().c_str());
}

I’ve pushed the changes into our internal review system, so this should make it to GitHub for our next milestone.

Thanks a lot for finding this!

-Kelly


#8

Hiya,

WOW! That’s quick work! Look forward to getting the next release.

No problems - if I find more, I’ll let you know.

One question - while you’re working on this, can you make the adef parser manage C++ files with the .cc extension as well as .cpp? I’m test porting code from other platforms to the Legato, and a lot of the code has .cc as the file extension. GCC doesn’t really care - it processes .cc as C++ by default.

I’m impressed!

Thanks, Dave


#9

Hey David,

Already done! We actually followed GCC’s example and the tools will now see all of the following as C++:
[ul]
.cc
.cp
.cxx
.cpp
.c++
.C
.CPP
[/ul]

Edit: Missed .CC in my list.

-Kelly


#10

Hi Kelly,

Great minds think alike :question:

Ta, Dave


#11

Hi Kelly,

Could you please tell us when the new adef parser will be available?

Thanks, Andrea


#12

The current plan is to have this in for the end of July.