octave-maintainers
[Top][All Lists]
Advanced

[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ë



reply via email to

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