Marc-André Moreau wrote, On 03/17/2011 02:05 AM: > Maybe we can deal with the problem this way: > > each "package" or library gets its folder in include/freerdp. For > instance, we would have: > > include/freerdp > include/freerdp/utils > include/freerdp/chanman > include/freerdp/gdi > include/freerdp/kbd > > Each of those "packages" would have a "global" header file, like this: > > include/freerdp.h > include/freerdp/utils.h > include/freerdp/chaman.h > include/freerdp/gdi.h > include/freerdp/kbd.h > > where each of those "global" headers would include all of the headers > within the associated subdirectory. Am I making sense? I'm just trying > to think of a cleaner way to organize things.
That would be very consistent, but it wouldn't reflect that the libraries have different natures: For utils it is a bad idea to use utils.h - instead the specific utils/something.h should be used. For for example kbd only kbd.h should be used - there is hardly any reason to use kbd/something.h directly. I would suggest that we drop utils.h and that we put all the content of for example kbd/*.h into kbd.h and drop the subfolder. It also seems inconsistent that the headers for libfreerdp should live in include/freerdp/*.h and be aggregated into include/freerdp.h . libfreerdp might be the primary entry point, but the other libraries are not particularly subordinate to it. I think it would be better to have include/freerdp/freerdp.h (and perhaps but preferably not include/freerdp/freerdp/*.h). We could perhaps also come up with a more specific name for this library - for example "rdp" or "protocol". A final nit in this ballpark: when working with the source code it is a bit annoying that everything is called libfreerdpsomething. It gives longer paths that isn't very easy to read and makes command line navigation harder - even with tab completion. We could perhaps drop the libfreerdp prefix internally. /Mads ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
