Re: OP_SRCDIR rule

[John W. Eaton]

On  1-Sep-2012, Daniel J Sebald wrote:

| On 09/01/2012 01:39 PM, Daniel J Sebald wrote:
| > On 09/01/2012 01:35 PM, John W. Eaton wrote:
| >> On 1-Sep-2012, Daniel J Sebald wrote:
| >>
| >> | Compilation appears to be proceeding, but I notice now there seems
| >> to be
| >> | duplicate includes:
| >> |
| > [snip]
| >> | i.e.,
| >> |
| >> | -I../liboctave/array -I../../octave/liboctave/array
| >>
| >> Are you building in the source tree?
| >>
| >> If you are building in a separate directory tree, then these will not
| >> be the same.
| >
| > Oh, that's right. There are both generated and non-generated files,
| > hence the multiple directories.
| 
| Only a few directories with generated header files actually:
| 
| liboctave/operators
| libinterp/
| libgnu/
| 
| so a lot of the included directories aren't need.  Not that critical.

Patch please?

| One thing I did notice is that you changed the order of inclusion to 
| make the compile work (I think).  Typically, header files are designed 
| so that order of inclusion isn't critical.  Are there header files with 
| the same name in the source tree somewhere?

There should not be.

| One thing that can be done (but I'm not saying it is the answer for 
| something in this case) is to include a directory in the header file 
| name used in the source code, e.g.:
| 
| #include <libgnu/stdio.h>

The stdio.h file is only present in libgnu if it is needed to fix
problems with the system stdio.h file on a particular platform.  In an
ideal world, with all bugs fixed in the standard header files, these
replacement headers and files from gnulib would not be needed.  So
including standard header files with a libgnu/ prefix is definitely
not the right thing to do.

| #include <libinterp/version.h>

I'd also rather not do this for Octave headers.  I don't want to have
to install them in a hierarchy, and I expect users would not want that
either.  It would represent a massive backward compatibility problem
for anyone who has written .oct files in the past.

jwe