Community
Participate
Working Groups
The TCF Agent Makefile currently uses a flat folder for all its contents. This has several drawbacks: * Browsing the code is not as easy as it could be, and it's harder for newbies to find the stuff they are looking for. We should separate the headers from the implementation, and probably separate the Core from the Services/Extensions/Main Programs. * Build Output should go to different folders depending on target architecture, such that multiple architectures or build/release variants can be built from the same sources. One option for achieving both goals would be to switch to using CDT Managed Build; but since the Agent is to be used in very constrained runtime environments (VxWorks or other RTOS), I'd prefer keeping the simple single Makefile and rewrite it to support - Output Directories WinDebug/WinRelease/CygwinDebug/CygwinRelease/ CygwinDebug/CygwinRelease/LinuxDebug/LinuxRelease/... - Separate Headers from implementation ("src", "include" folders) I'm not sure if any further separation into Core/Services/Mains makes sense so I'd like to defer this to a second step for now. Any comments or feedback?
Note that daytime build system also needs to adapt to any restructuring.
...And service-adding agents should be able to link against precompiled agent lib rather than having to build all the agent again themselves.
Proposal for new agent directory structure: SVNROOT + projects | + common | | + framework | | | + protocol.c | | | + protocol.h | | | + channel.c | | | + channel.h | | | + … | | + services | | | + runctrl.c | | | + runctrl.h | | | + memoryservice.c | | | + memoryservice.h | | | + … | | + mdep | | | + arch.c | | | + arch.h | | | + arch_x86.c | | | + arch_x86.h | | | + arch_ppc.c | | | + arch_ppc.h | | | + mdep.c | | | + mdep.h | | | + mdep_thread.c | | | + mdep_thread.h | | | + mdep_socket.c | | | + mdep_socket.h | + agent | | + Makefile | | + config.h | | + main.c | + value-add | | + Makefile | | + config.h | | + main.c | + tcf-log | | + Makefile | | + config.h | | + … Notes: - The Makefile in each project directory (other than common) would create a sub directory containing the object and/or archive files and generated executable. - Specific functionality in mdep.[ch] will be separated since most files should not depend on it. For example threading and socket handling should be kept localized as much as possible. - The mdep directory contains both processor architecture specific as well as runtime environment (machine) specific information. This could be split up, but since the directory will be relative small it may not be necessary. Comments are welcome!
Looks much better than the flat structure now. But I'd suggest to create a directory per service. Or do the services depend on each other? And why are the services under common?
(In reply to comment #4) > Looks much better than the flat structure now. But I'd suggest to create a > directory per service. Or do the services depend on each other? Service interfaces are designed to have minimal dependencies, but the underlying implementation may have dependencies. > And why are the services under common? It is under common because we wanted to reduce the number of top level directories because each would map to an eclipse project.
(In reply to comment #5) Given that each service is typically just one header and one c file, I'm ok with keeping the proposed structure rather than fostering an explosion of directories. I do not think that top level directories necessarily map to Eclipse projects. We can still have all the TCF plain C implementation in one Eclipse project just as we do now, and actually I think I'd prefer that over having separate Eclipse projects just for the value-add or for the agent, with just 4-5 files in them. Let's keep the administrative overhead as small as possible. Having services under "common" seems OK for me considering that the common stuff is re-used by the various main programs (tcflog, agent, value-add) and thus makes up kind of a tcf "library".
With the current proposal, most OS dependent stuff is localized to mdep.[ch]. Which means that if someone wants to port the agent to a proprietary OS, he has to add proprietary OS dependent code into those files. By doing this, he will expose some of his private APIs/data structures, which is not acceptable. To resolve this, I propose to split those files into OS dependent files. For example: mdep_win32.[ch], mdep_unix.[ch], ...
I would also like to see some uniform naming convention. t would be great if the header files would have some structure when included. Instead of #include "link.h" I'd like to see a tcf prefix: either #include "tcf_link.h" or #include "tcf/link.h" or #include "tcf/framework/link.h" The flat include can easily lead to unwanted name clashes, because names like link.h channel.h events.h myalloc.h ... Have a high chance to clash with other includes.
...I think it is time to fix this bug (see bug 257261)
There was an idea to wrap the TCF agent as one or more RTSC components. RTSC could actually help managing the services installed into the agent, as well as the target build platforms -- plus, it could probably help offloading some tracing/logging/debugging code from the agent into the host, to make the agent even smaller.
See also http://www.eclipse.org/newsportal/article.php?id=45&group=eclipse.dsdp.rtsc#45
Created attachment 142943 [details] Proposal patch for TCF plugins system. Here is the patch for a basic plugins system support. In the modified Makefile, the plugins system is disabled by default. To enable it, you have to specifity a plugins path, where the compiled agent is going to search for valid plugins. The plugins path may be specified to `make' like this: make PATH_Plugins="/absolute/path/to/the/plugins" TCF plugins have to be compiled/linked as shared libraries (see http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Program-Library-HOWTO.html#AEN95 ). For example, a plugin `myplugin.so' made of `myplugin.c' and `tools.c' should be built this way: $ gcc -fPIC -c -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -Wmissing-prototypes -Wno-parentheses -I path/to/tcf-agent/ myplugin.c tools.c $ gcc -shared -Wl,-soname,myplugin.so -o myplugin.so myplugin.o tools.o -lc When the agent loads, the plugins system will call, for each .so found, the function "tcf_init_plugin". Thus, the only function that's going to be called by the system in your plugin should have this prototype: void tcf_init_plugin(Protocol *, TCFBroadcastGroup *, TCFSuspendGroup *); The plugin's function "tcf_init_plugin" has the same purpose as the services initialization functions. This patch has been applied and tested on SVN revision 760 of the C TCF agent under Linux. The plugins system is only implemented on UNIX-based systems for now (because it uses libdl functions), but could possibly be extended to other systems using other mechanisms. What do you think about it? Comments, suggestions? Legal Message: I, Philippe Proulx, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL and EDL. I am authorized by my employer, École Polytechnique de Montréal, to make this contribution under the EPL and EDL. The École Polytechnique de Montréal is a member of the Eclipse Associate and Eclipse Membership At Large communities.
I believe plugins support is very valuable feature. I have committed the patch. I renamed EN_Plugins to ENABLE_Plugins for consistency, and made few other cosmetic changes. Thanks for the contribution. Eugene.
Philippe, this is a great contribution! Many thanks for it. My only small concern is, that the plugins system actually solves a different problem than we are discussing on this bug (which is meant to deal with the build directory structure, and static componentization). There are many types of system which may not even have shared library support, so keeping your excellent contributino separate from the static build would be helpful. Philippe, could you create a new enhancement request ("TCF plugins system"), with your same text from comment 12 as description, and attach your code there? - This would help us in tracking everything properly. Thanks!
Comment on attachment 142943 [details] Proposal patch for TCF plugins system. The TCF plugins system has been committed via bug 286149.
