Re: [RFC] Include file structuring.
On 18 October 2013 19:16, Andrew MacLeod wrote: > So I think I am in favour of no includes in .h files... It may make it more > obvious when a file is using some other inappropriate file for something, > and it is easier for my simple analysis tools to find poor export > candidates. > > I will also note that our list of 3 to start the file would now become: > > #include "config.h" > #include "hwint.h" > #include "system.h" > #include "coretypes.h" > > since system.h currently includes hwint.h :-) In the case of header files that have to be included by every .c file, it does not help with fixing modularity/dependency issues to force the .c files to include all the dependencies of the header file, even those that don't define any interfaces of their own (as opposed of ones used solely by including header files, or being part of the interface definition of the including file) that are to be used by the .c files. It might make sense to break up system.h into different files to group specific features together, or to break up config.h to include files generated in different parts. The choice of a monolithic header file or an include tree are implementation details of the header file, yet with the rigid no-include-includes policy, we force these implementation details into each consumer .c file.
Re: [RFC] Include file structuring.
On 10/22/2013 08:27 AM, Joern Rennecke wrote: On 18 October 2013 19:16, Andrew MacLeod wrote: So I think I am in favour of no includes in .h files... It may make it more obvious when a file is using some other inappropriate file for something, and it is easier for my simple analysis tools to find poor export candidates. I will also note that our list of 3 to start the file would now become: #include "config.h" #include "hwint.h" #include "system.h" #include "coretypes.h" since system.h currently includes hwint.h :-) In the case of header files that have to be included by every .c file, it does not help with fixing modularity/dependency issues to force the .c files to include all the dependencies of the header file, even those that don't define any interfaces of their own (as opposed of ones used solely by including header files, or being part of the interface definition of the including file) that are to be used by the .c files. I would expect that when we eventually get everything sorted out, the implementation files will simply include these "required" files, so most .c files will probably start with only one of: #include "tree.h" or #include "gimple.h" or #include "rtl.h" and get all the "basics" that are required. that would be nice... :-P It might make sense to break up system.h into different files to group specific features together, or to break up config.h to include files generated in different parts. The choice of a monolithic header file or an include tree are implementation details of the header file, yet with the rigid no-include-includes policy, we force these implementation details into each consumer .c file. I think this is transitional. Its such a mess right now, that I think we need to flatten the entire thing, and then rebuild it with some modular design in place such that routines and data structures are where they belong. then we can consider including things that are prerequesites. I don't think we'll live by a draconian rule of "no include shall ever include another include"... but we need to at least head in that general direction to figure out what bits are where and who requires them. Andrew
Include file visibility scopes? (Was: Re: [RFC] Include file structuring.)
On 22 October 2013 21:07, Andrew MacLeod wrote: > I think this is transitional. Its such a mess right now, that I think we > need to flatten the entire thing, and then rebuild it with some modular > design in place such that routines and data structures are where they > belong. then we can consider including things that are prerequesites. Hmm. It seems this include dependency morass is really a trap for any big C / C++ project. And once you have straightened it out, it'll might creep back over the years as more data structure redesign and refactoring goes on. I wonder what it'd take to have a cpp extension to include a file in such a manner as to emit a diagnostic if the items declared / #defined inside are used directly by a file that includes the file that does the thus guarded include. We already have some tracking of where source comes from now for the purposes of printing include backtraces... Woud probably want to re-set the usable scope if there is a later include of the same file, mutliple-include-guards notwithstanding...
Re: Cilk Library
On 10/16/13 13:30, Iyer, Balaji V wrote: First, the all issues Joseph mentioned need to be addressed. So first, you need to ensure it's only being built on x86/x86_64 given the asms and bring together some documentation as to what's needed to port the runtime system to other architectures. Closely related, I think you initially need to ensure it only builds on x86-linux platforms -- unless you've already verified it works properly on one or more of the bsd platforms, solaris, windows, etc. We are in the process of addressing all these. I will send out an email with the fixed runtime as soon as I can. Excellent. THanks. I would strongly echo Joseph's recommendation to ensure that only those symbols specifically intended to be part of the public interface are exported from the shared library. How stable has the exported API/ABI for Cilk+ been?Related: how clean is the RTS from a compile-time namespace pollution standpoint. For C++ is everything in a namespace, for C is everything prefixed appropriately? We are currently verifying those and making sure only the required symbols are exported. IMHO, the best way to do this is with linker scripts and it's an excellent time ot drop in versioning information. I'd think this would be useful for ICC as well. This is probably the biggest issue. I'll note Richi chimed in on this as well. Look at libatomic/libatomic.map and how that gets used. It gives you full control over the exports. jeff
