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 <[email protected]>: > 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 <[email protected]>: >> >>> 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 >> [email protected] >> http://mail.gnome.org/mailman/listinfo/orbit-list >> > > _______________________________________________ orbit-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/orbit-list
