[OPEN-ILS-DEV] oils_utils.h et alia

[Dan Scott]

On 14/11/2007, Scott McKellar <mck9 at swbell.net> wrote:
>
> --- Bill Erickson <erickson at esilibrary.com> wrote:
>
> > Mike Rylander wrote:
> > > On Nov 14, 2007 12:00 AM, Scott McKellar <mck9 at swbell.net> wrote:
> > >
> > >> Where is oils_utils.h supposed to reside?  ...and where or what is
> > >> the openils directory?
> > >>
> > >> In ils/trunk/ the only file by named oils_utils.h is in
> > >> Open-ILS/src/c-apps/, where also reside four .c files that
> > #include it.
> > >>
> > >> However the file Open-ILS/src/extras/oils_requestor.c #includes
> > >> "openils/oils_utils.h".  I see no directory named "openils" in the
> > >> repository trunk.
> > >>
> > >> Elsewhere I see references to other header files in this
> > non-existent
> > >> directory: idl_fieldmapper.h, fieldmapper_lookup.h, and
> > oils_event.h.
> > >> Of these, two are in the c-apps directory and another is in the
> > >> apachemods directory.
> > >>
> > >> What's up with that?  Unless you have some funky links that aren't
> > >> reflected in the repository, I don't see how some of these files
> > >> can even compile.
> > >>
> > >>
> > >
> > > These are moved into a single temp dir by the build process and (by
> > > default, during the build) live in trunk/ILS/.tmp/
> > >
> > > My understanding of Bill's purpose there was to keep everything in
> > one
> > > place at build time to reduce confusion back when a whole lot more
> > was
> > > being built in the ILS tree -- back when OpenSRF and Evergreen were
> > in
> > > one repo.
> > >
> >
> > I think awkward evolution defines it a little better.  In my opinion,
> >
> > the ILS C headers need the same treatment the OpenSRF headers
> > received
> > when OpenSRF was given its own repository.  Any shared headers should
> > go
> > into a new Open-ILS/include/openils/ directory,
> > -Ipath/to/Open-ILS/include should be appended to CFLAGS for the
> > various
> > makefiles, and all C files should #include the fully qualified
> > <openils/some_header.h>.
> >
> > Thoughts?
> >
> > -bill
>
> I agree.  Except where there is some persuasive reason to the
> contrary, the directory structure within the repository should
> reflect the directory structure of the build environment.  That way
> you don't need to understand the build in order to understand the
> code.
>
> That said, I can live with it either way.  What I don't like is
> having different files #include the same header in different ways:
>
>     #include "oils_utils.h"
>     #include "openils/oils_utils.h"
>
> There is some virtue in consistency.

+1 for #include "openils/oils_utils.h"

(To put my money where my mouth is, I'm also willing to rework the
build accordingly)

-- 
Dan Scott
Laurentian University