[OPEN-ILS-DEV] oils_utils.h et alia
Bill Erickson
erickson at esilibrary.com
Wed Nov 14 14:22:35 EST 2007
Dan Scott wrote:
> 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++
--
Bill Erickson
| VP, Software Development & Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com
More information about the Open-ils-dev
mailing list