Re: Crosscompiling ORBit2

[Guillermo Sanchez <guillersan gmail com>]

Hi Frank,

Thank you again. I really think I'm not explaining well where my
trouble is. I'm sorry.

First I create the idl file: myfile.idl

After using the IDL compiler on myfile.idl by tiping in console:

orbit-idl-2 --skeleton-impl myfile.idl

I get:

DO NOT EDIT
---------------------
myfile-stubs.c
myfile-skels.c
myfile-common.c
myfile.h

TO EDIT
-------------
myfile-skelimpl.c

TO CREATE
-------------------
myfile-client.c
myfile-server.c

After client and server creation (server is almost C&P-ed from another
server file) I fill the skelimpl file with my code, just where it said

/************PUT YOUR CODE HERE************/
My code.
/************END OF YOUR CODE***************/

After that, I have to compile the server and client in order to get an
executable. And here is when the trouble comes.

I want to the get executable done just by tiping "make" in console.
Like in the "echo" example. But I have to edit the Makefile to change
some things. I need to add flags and includes to compile it with RTAI.
An there is where my knowledge ends.

I got the includes and the prefixes for RTAI from another compilation,
something like this:

$(CC) $(LXRT_CFLAGS) -o $@ $< $(LXRT_LDFLAGS) -llxrt

And to compile :

gcc -o server 'pkg-config --cflags --libs ORBit-2.0' myfile-skelimpl.c
myfile-common.c myfile-skels.c

I need a common command for both of them, something like:

server:
$(CC) $(LXRT_CFLAGS) $(CFLAGS) -o pkg-config $@ $< myfile-skelimpl.c
myfile-common.c myfile-skels.c $(LXRT_LDFLAGS) -llxrt $(LDFLAGS)

Thanks.

Cheers,

Guillermo

2009/7/24 Frank Rehberger <Frank Rehberger web de>:
> Guillermo Sanchez wrote:
>> Hi Frank,
>>
>> Thanks a lot for your answer. But I have no trouble in the stubs and
>> skels creation through idl compilation - After running the "echo"
>> example one hundred times i finally got it.
>>
>> My troubles appears in the next stage when compiling the server,
>> client and skeleton implementation "classname-skelimp.c". I simply
>> don't know where the flags are applied or where the compilation is
>> done in the Makefile file. I know it has to be here:
>>
>>        $(ORBIT_IDL) --skeleton-impl $^
>>
>> But I don't know what is it doing or what's going on and I need to add
>> some flags.
>>
> Talking in terms of C++ or Java, the skeleton-impl inherits from
> skeleton, implementing the (well) "virtual" skeleton-methods.
> As the "inheriting"  in pure C this is a bit cumbersome, the IDL
> compiler provides a feature to generate the corresponding skeleton-impl
> code (method-templates and vtables), so you just have got to add your
> code into the method templates.
>
> The skeleton-impl generation stuff is done once only, as long as IDL
> does not change. Mind that changing the IDL you might want to repeat
> the  skeleton-impl generation, merging in your code again later.
>
> Regards, Frank
>
>> The thread question comes because to use some RTAI funtions I have to
>> launch a couple of threads. Threads that aren't going to give a
>> response they will just be created, do their stuff in the server side
>> and be destroyed every time I need them.
>>
>> Again thank you very much for the info.
>>
>> Cheers,
>>
>> Guillermo
>>
>> 2009/7/23 Frank Rehberger <Frank Rehberger web de>:
>>
>>> Guillermo Sanchez wrote:
>>>
>>>> Hello collisters:
>>>>
>>>> I'm quite new in the ORBit world, so sorry if this is not the correct
>>>> way of asking things.
>>>>
>>>> I wanted to compile an ORBit program (server, client, skelimp...)
>>>> using RTAI flags (Real Time Aplication Interface) and includes, since
>>>> I'm using this last to communicate ORBit with a real time process. I
>>>> thought it would be a matter of makefile edition but when I edited it
>>>> I realized how new I'm in this world. Indeed I don't know where ORBit2
>>>> compiles at all.
>>>>
>>>>
>>>>
>>> first you need to invoke the IDL compiler which generates the C code for
>>> your IDL interfaces, this way you will get the stubs and skeletons.
>>>
>>> $(IDLOUT): Uneje.idl
>>>        $(ORBIT_IDL) Uneje.idl
>>>
>>>
>>> The skeletons are for the server-side, the stubs for the client side.
>>>
>>> These files are ordinary C files which can be compiled to object files
>>> with gcc.
>>>
>>> On server side you will need also to implement the skeletons, commonly
>>> called "classname-skeleton-impl.c", which implement the logic of your
>>> server.
>>>
>>> Hope that helps.
>>>
>>>
>>>> By the way, is there any difference between using g_thread_create and
>>>> pthread_create?
>>>>
>>>>
>>> little, g_thread_create will be mapped onto pthread_create, but for
>>> portability it is better to choose g_thread_create, which might also do
>>> some magic in background.
>>>
>>>
>>>> Also, can I create a thread inside the skeleton implementation code?
>>>>
>>>>
>>> Off course you can, but if it is about to calculate a return value, you
>>> should not.
>>>
>>> Instead, the requests are managed by the POA, the portable object
>>> adapter. This Adapter will be initialized with so called
>>> concurrency-policy, which can be "single-threaded",
>>> "thread-per-connection" or a "system" specific threaded policy. AFAICS,
>>> thread per connection is the best choice for RealTime applications. This
>>> way each client (alias connection) would be associated with a specific
>>> thread on server side, and requests of high priorized clients would not
>>> share thread-resources with requests of low priorized threads. RT-CORBA
>>> defines a n umber of thread-pool features, but they are not implemented
>>> for ORBit2 yet (AFAIK).
>>>
>>> Regards, Frank
>>>
>>>
>> _______________________________________________
>> orbit-list mailing list
>> orbit-list gnome org
>> http://mail.gnome.org/mailman/listinfo/orbit-list
>>
>
>