Re: [OPEN-ILS-DEV] oils_utils.h et alia
--- Bill Erickson [EMAIL PROTECTED] wrote: Mike Rylander wrote: On Nov 14, 2007 12:00 AM, Scott McKellar [EMAIL PROTECTED] 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. Scott McKellar http://home.swbell.net/mck9/ct/
Re: [OPEN-ILS-DEV] oils_utils.h et alia
On 14/11/2007, Scott McKellar [EMAIL PROTECTED] wrote: --- Bill Erickson [EMAIL PROTECTED] wrote: Mike Rylander wrote: On Nov 14, 2007 12:00 AM, Scott McKellar [EMAIL PROTECTED] 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
Re: [OPEN-ILS-DEV] oils_utils.h et alia
Dan Scott wrote: On 14/11/2007, Scott McKellar [EMAIL PROTECTED] wrote: --- Bill Erickson [EMAIL PROTECTED] wrote: Mike Rylander wrote: On Nov 14, 2007 12:00 AM, Scott McKellar [EMAIL PROTECTED] 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: [EMAIL PROTECTED] | web: http://esilibrary.com
