On May 24, 2013, at 03:54 , Marvin Humphrey <[email protected]> wrote:
> On Mon, May 20, 2013 at 12:09 PM, <[email protected]> wrote: > >> Add parcel prefix to parcel.c and parcel.h >> >> The parcel header file must be publicly available, so add parcel prefix >> to avoid name clashes. > >> Project: http://git-wip-us.apache.org/repos/asf/lucy/repo >> Commit: http://git-wip-us.apache.org/repos/asf/lucy/commit/fd43a656 >> Tree: http://git-wip-us.apache.org/repos/asf/lucy/tree/fd43a656 >> Diff: http://git-wip-us.apache.org/repos/asf/lucy/diff/fd43a656 > >> - scratch = chaz_Util_join(dir_sep, "autogen", "source", "parcel.c", >> NULL); >> + scratch = chaz_Util_join(dir_sep, "autogen", "source", "lucy_parcel.c", >> + NULL); > > This bugs me because it's not extendable to fully qualified parcel namespaces, > but it's suggested a tangential idea: What's the rationale for fully qualified parcel namespaces exactly? Is it to work around possible name clashes of parcel prefixes? > How about eliminating the "autogen" directory and having all our output go > into .h files? Then we can drop them alongside the .cfh files we used to > generate them. > > core/Lucy/Search/IndexSearcher.cfh // in > core/Lucy/Search/IndexSearcher.h // out > > There's a certain amount of tangible .c code that we generate, but maybe we > can stick that in a .h file and enclose it with ifdefs which only one .c file > defines. > > #ifdef C_LUCY_INDEXSEARCHER > // .... > #endif > > The rationale is to make the connection between the .cfh source files and the > generated .h files clearer so that it's easier to for both newcomers and > experts to see what's going on. +1 for creating the per-class .h files next to the .cfh files. It only makes installation of the header files for the C library a bit more complicated. -1 for moving the generated .c code to the .h files. I don't see a problem with the way we generate the .c files right now. Furthermore, there is some per-parcel C code where there isn't a particular class it belongs to. I also don't want to put more internal stuff in the installed headers. They already take up considerable space. Here's an example of the footprint of a C library installation on OS X: $ du -sch lucy/* 6.3M lucy/include 2.4M lucy/lib 372K lucy/man 9.1M total It's not really a problem but I find it interesting that the headers take up more than two times the space of the binary. They're even more than three times the size of the stripped binary. Nick
