[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Better name for cruft directory
From: |
Carnë Draug |
Subject: |
Re: Better name for cruft directory |
Date: |
Sat, 22 Apr 2017 18:53:06 +0100 |
On 22 April 2017 at 15:01, Rik <address@hidden> wrote:
> On 04/22/2017 05:59 AM, John W. Eaton wrote:
>> On 04/21/2017 11:34 PM, Daniel J Sebald wrote:
>>
>>> Faddeeva
>>> --------
>>> Some C++ code (actually may be C code that can be compiled as either)
>>> related to only erf() functions. It has a fairly recent copyright of
>>> 2012, so I assume it must be used in some way, as fallback code or
>>> something. Could this go in some other directory? I know there has
>>> been a lot of development around erf so maybe there is a more logical
>>> place.
>>
>> Like most of the other code in cruft, this is code that is maintained (or
>> not) separately from Octave but for which there is no package available
>> in any Linux distribution that I know of, so we include a copy in the
>> Octave sources. So I'd like to keep files like this separate from the
>> rest of the Octave sources rather than dumping it in with other Octave
>> source code.
>>
>>> Misc
>>> ----
>>> quit.cc,quit.h: Is Octave code, very short. Seems an odd place for
>>> quit-related code to be since there is probably a lot of start/quit code
>>> elsewhere.
>>
>> These need to be in liboctave (previously, in libcruft) because they need
>> to be available for all of Octave, not just libinterp. When libcruft was
>> a separate library from liboctave, this location made more sense.
>>
>>> cquit.c: Again, Octave code, very short. Could probably combine quit.cc
>>> and cquit.c into one file in some way.
>>
>> Maybe, but the reason it is separate is so that it will be compiled with
>> a C compiler, not a C++ compiler, in order to avoid warnings.
>>
>> I moved the files in liboctave/cruft/misc to liboctave/util in this
>> changeset:
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/58d56f52d50a
>>
>> For the rest, how about just renaming liboctave/cruft to be
>> liboctave/external?
>
> That would work for me.
>
> My only slight concern is that it will be confused with the External Code
> Interface documented in Appendix A. But, if you are mucking about in
> liboctave you probably already understand a lot about the code base.
>
> --Rik
3rd-party and vendor are common names for this things too.
Carnë