> I have to admit that I'm > always a little unhappy about including .c files because it confuses > anyone looking at how the system is built.
Though as a technique it is widely used in the fltk code base, to handle cross-platform builds and so forth. I don't see it as a problem here. > As it looks like we will probably have to change his file anyway, it > might be easier to simply use his file as normal, rather than #include > it, and simply comment out (#if 0) the unwanted routines. We access > via the fl_wcwidth() wrapper name. The fl_wcwidth() will have doxygen > comments and appear in the documentation, and mk_wcwidth() will not. Though, if we are "tweaking" the MK file anyway, it might be best to stick with the #include approach, *and* to "adjust" the mk_* functions to be explicitly static, so that only the fl_wrapper functions are visible to the users at all? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
