octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OP_SRCDIR rule


From: Rik
Subject: Re: OP_SRCDIR rule
Date: Sat, 01 Sep 2012 18:28:31 -0700

On 09/01/2012 02:37 PM, Daniel J Sebald wrote:
> On 09/01/2012 04:00 PM, John W. Eaton wrote:
>> On  1-Sep-2012, Daniel J Sebald wrote:
>>
>> | How about if "version.h" and "oct-conf.h" were placed in the ./ root of
>> | the build-directory as opposed into ./libinterp?  Their contents look to
>> | be something appropriate to the highest level, or are they particular to
>> | libinterp?  That would mean that none of the build-directory paths would
>> | need be included, and that -I../libgnu and -I../../octave/libgnu would
>> | only be included if there were a need to replace existing header files?
>>
>> Maybe version.h should be moved.  I think oct-conf.h is only used by
>> code inside the libinterp directory.
>>
>> In my build tree, I see the following generated header files:
>
> [snip]
>
>> I really don't care if there are many -I options. What trouble does it
>> cause for you?
>
> Not much.  Rik raised the issue early on when he started the re-org.
> Internally, the compiler is just having to search more directories until
> it finds an appropriate file.  The only problem is if including a whole
> host of directories is covering up for somewhat sloppy programming
> whereby header files are being included that don't need to be, e.g.,
> sparse headers in some obscure library.  The change is that a lot of
> files used to be in one directory meaning that only a few include paths
> were needed but they were always necessary.  By filtering things into
> subdirectories, there are more paths to include, but paths aren't always
> needed because of the narrowing of the subdirectories' scope.
Dan,

You mentioned the issue that was foremost on my mind when I raised the
issue--sloppiness might be covering up bad programming.  I also find it
difficult simply to understand the compile command when it is a half page
long so fewer includes and a more concise compile are appealing. 

I will see about removing unnecessary includes.  In addition, the actual
order of includes can be important and some systems, like MinGW, are also
incredibly fussy about link order.  I think a user on that system will give
us feedback about what works and what doesn't.

--Rik


reply via email to

[Prev in Thread] Current Thread [Next in Thread]