Good point, Dan. One simple question from the path issue. Do you comment on installed header path or development source itself? Developer perspective this well organized path is important but this is installed header view point.
BR, Uze Choi -----Original Message----- From: Daniel Mihai [mailto:[email protected]] Sent: Saturday, March 25, 2017 9:48 AM To: ??? (Uze Choi); 'Nash, George'; 'Philippe Coval'; iotivity-dev at lists.iotivity.org Subject: RE: [Iotivity-maintainers] [dev] C API docs: which Doxyfile? I corrected my "undesirable stdlib path" example path below: -----Original Message----- From: Daniel Mihai Sent: Friday, March 24, 2017 2:12 PM To: '??? (Uze Choi)' <uzchoi at samsung.com>; 'Nash, George' <george.nash at intel.com>; 'Philippe Coval' <philippe.coval at osg.samsung.com>; iotivity-dev at lists.iotivity.org Subject: RE: [Iotivity-maintainers] [dev] C API docs: which Doxyfile? This is not a big deal but my opinion is that having a single header file for each directory under c_common is an inefficient use of directories. I look at c_common as similar to "the IoTivity CRT". I believe that a typical CRT has malloc.h and stdlib.h in a single directory. There is no: <path to CRT>/malloc/include/malloc.h or <path to CRT>/stdlib/include/stdlib.h and programmers don't have to remember such different paths. Similarly, I think oic_malloc.h and oic_string.h should live in a single common/include (assuming that both of these headers are intended to be Public). Dan -----Original Message----- From: ??? (Uze Choi) [mailto:[email protected]] Sent: Thursday, March 23, 2017 10:03 PM To: Daniel Mihai <Daniel.Mihai at microsoft.com>; 'Nash, George' <george.nash at intel.com>; 'Philippe Coval' <philippe.coval at osg.samsung.com>; iotivity-dev at lists.iotivity.org Subject: RE: [Iotivity-maintainers] [dev] C API docs: which Doxyfile? First of all, resource/c_common/include for all headers under the resource/c_common is acceptable idea? Any issue from here or good technic? BR, Uze Choi -----Original Message----- From: Daniel Mihai [mailto:[email protected]] Sent: Friday, March 24, 2017 12:02 AM To: ??? (Uze Choi); 'Nash, George'; 'Philippe Coval'; iotivity-maintainers at lists.iotivity Subject: RE: [Iotivity-maintainers] [dev] C API docs: which Doxyfile? I agree with Uze. (I thought that was already the proposal we were discussing) Dan -----Original Message----- From: ??? (Uze Choi) [mailto:[email protected]] Sent: Thursday, March 23, 2017 3:50 AM To: Daniel Mihai <Daniel.Mihai at microsoft.com>; 'Nash, George' <george.nash at intel.com>; 'Philippe Coval' <philippe.coval at osg.samsung.com>; iotivity-maintainers at lists.iotivity Subject: RE: [Iotivity-maintainers] [dev] C API docs: which Doxyfile? Let me continue the directory restructuring for header file. Merging all header file into single directory looks not feasible because of separate sub project from iotivity internally. How about placing them into some sets of directory normalized feature level unit such as common, security, resource-directory, routing, connectivity, include(base). This can lead simpler structure also. BR, Uze Choi -----Original Message----- From: iotivity-maintainers-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Daniel Mihai via Iotivity-maintainers Sent: Saturday, March 18, 2017 3:48 AM To: Nash, George; Philippe Coval; iotivity-maintainers at lists.iotivity.org Subject: Re: [Iotivity-maintainers] [dev] C API docs: which Doxyfile? I like the proposals so far. Here are my current thoughts: 1. We should move the non-Public resource/c_common header files into resource/c_common/src. 2. For Public resource/c_common header files: no need for ./resource/c_common/include/iotivity/oic_malloc or ./resource/c_common/include/iotivity/oic_string. Instead of those two separate paths, we should use a single ./resource/c_common/include/iotivity. Dan -----Original Message----- From: iotivity-maintainers-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Nash, George Sent: Friday, March 17, 2017 11:17 AM To: Philippe Coval <philippe.coval at osg.samsung.com>; iotivity-maintainers at lists.iotivity.org Subject: Re: [Iotivity-maintainers] [dev] C API docs: which Doxyfile? I personally like the idea of having everything in an iotivity namespace. Not sure I like the idea of having the `resource` be part of the path. In my opinion the best solution would be a slight re-organization of the headers. I would reverse the folder structure instead of <component>/include it should be include/iotivity/<component> Example: ./resource/c_common/octhread/include -> ./resource/c_common/include/iotivity/octhread ./resource/c_common/oic_malloc/include -> ./resource/c_common/include/iotivity/octhread ./resource/c_common/oic_time/include -> ./resource/c_common/include/iotivity/oic_time ./resource/c_common/oic_string/include -> ./resource/c_common/include/ iotivity/oic_string ./resource/c_common/windows/include -> ./resource/c_common/include/ iotivity/windows ./resource/c_common/ocrandom/include -> ./resource/c_common/include/ iotivity/ocrandom This would reorganize the structure so the CPPPATH would be the locations CPPPATH= [?#/resource/c_common/include?, ?#/resource/csdk/include?, ?#resource/include?] In the code the #include could use the path style inclusion. (if for some reason we don?t want to use path style inclusion we could still put the full path in the CPPPATH) i.e. #include <iotivity/octhread/octhread.h> #include <iotivity/ocrandom/ocrandom.h> #include <iotivity/foo.h> All iotivity headers would start with `iotivity/` a lot of other projects have done a similar approach. This simple organization change helps but it does not tell which are intended for general public use and which are internal to the project itself. The AllJoyn project solved the public header issue in a simple way. If the header was in the include directory it was public. Anything not public was placed in the src directory. IoTivity already does something similar to this using the `include/internal` directory to indicate headers that are not public. Maybe we just need to do a check to make sure all intern headers end up in an internal directory. In addition would also suggest all include directories be named 'include' none should be named 'inc'. The naming is currently inconsistent across the entire code base. George -----Original Message----- From: iotivity-maintainers-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Philippe Coval Sent: Friday, March 17, 2017 4:58 AM To: iotivity-maintainers at lists.iotivity.org Subject: Re: [Iotivity-maintainers] [dev] C API docs: which Doxyfile? On 17/03/17 12:36, Ashok Babu Channa wrote: > Move all header files under csdk/include makes appropriate from my opinion. > > resource/include - C++ API > resource/csdk/include- CAPI. > > Regards,ok Sounds good, may I suggest that we use also iotivity namespace prefix path ? Just like: - resource/include/iotivity/resource (C++) - resource/include/iotivity/resource/csdk/ (C) This way we can use "rooted path" (in headers at least) like #include <iotivity/resource/csdk/foo.h> it will work in source tree and installed on system (in /usr/include/iotivity) In the end endless pathes flags will be not needed (-I... from pkgconfig), because all headers will be relative to iotivity namespace path. I can explain further the plan on jira if needed. Regards -- mailto:philippe.coval at osg.samsung.com gpg:0x467094BC https://blogs.s-osg.org/author/pcoval/ _______________________________________________ Iotivity-maintainers mailing list Iotivity-maintainers at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-maintainers _______________________________________________ Iotivity-maintainers mailing list Iotivity-maintainers at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-maintainers _______________________________________________ Iotivity-maintainers mailing list Iotivity-maintainers at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-maintainers
