Remove build-osx.txt, build-solaris.txt, and misc-notes.txt.

The first two are utterly obsolete and the third copies a mailing
list conversation from 20 years ago about stock splits.
This commit is contained in:
John Ralls 2019-06-29 14:10:23 -07:00
parent d53649c061
commit e148477c70
4 changed files with 2 additions and 166 deletions

View File

@ -19,8 +19,8 @@ set(doc_DATA
)
set(doc_noinst_DATA
build-aix.txt build-solaris.txt CMakeLists.txt gnc-fq-dump.1 gnc-fq-helper.1 gnucash.1.in
misc-notes.txt README.HBCI README.OFX README.translator.txt tip_of_the_day.list.c
CMakeLists.txt gnc-fq-dump.1 gnc-fq-helper.1 gnucash.1.in
README.HBCI README.OFX README.translator.txt tip_of_the_day.list.c
TRANSLATION_HOWTO)
install(FILES ${doc_DATA} DESTINATION ${CMAKE_INSTALL_DOCDIR})

View File

@ -1,72 +0,0 @@
/** \page osxbuild Building GnuCash on OSX
\section dependency Automake dependency
automake1.4 is NOT compatible with gnucash on OSX. If fink replaces
a later automake during an update of other packages, you will need
to replace with a later version. Fink will then remove automake1.4
in favour of the later version. GnuCash has been tested on OSX with
automake1.9
\section building Build advice
'make uninstall' may not be sufficient - when rebuilding in the same
source tree, remove the installation directory with 'rm -rf'.
\section osxprepare Preparation
There are notable problems building gnucash with the default
auto tools installed in OSX and even installing the GNU versions
via fink may not be sufficient - OSX may still call the BSD version
in preference to the newly installed GNU version.
To avoid these problems, you are advised to change your PATH variable
in ~/.bashrc to put the Fink binaries ahead of the main OSX binaries
in your path or export a new PATH in the script that calls autogen.sh.
Instead of:
\verbatim
PATH=/usr/bin/:/sbin/:/usr/sbin/:/bin:/opt/local/bin:/sw/bin
/endverbatim
use:
/verbatim
PATH=/sw/bin:/usr/bin/:/sbin/:/usr/sbin/:/bin:/opt/local/bin
/endverbatim
Then, when calling ./autogen.sh and ./configure, it is necessary
to direct OSX to the correct Guile installation environment using:
\verbatim
#!/bin/bash
guile16-build env LIBRARY_PATH=/sw/lib CPATH=/sw/include \
./autogen.sh
guile16-build env LIBRARY_PATH=/sw/lib CPATH=/sw/include \
./configure <your configure options>
guile16-build env LIBRARY_PATH=/sw/lib CPATH=/sw/include \
make
\endverbatim
If (when) you do a 'make distclean', this whole process will have to
be done again.
If you have to change automake or autoconf versions, make sure you
remove the autom4te.cache/ directory before running autogen.sh again.
\section osxtools OSX tools
GnuCash recommends <b>only>/b> the most recent versions of each of the
GNU auto tools available via Fink. As of November 2005, these were:
\verbatim
10.3 10.4
autoconf2.5 2.59-6 2.59-6
automake1.9 1.9.5-1 1.9.6-1
libtool14 1.5.18-1 1.5.20-1
\endverbatim
Currently, these versions are only available in the unstable (CVS) version
of Fink.
http://pdb.finkproject.org/index.php
*/

View File

@ -1,10 +0,0 @@
Solaris hints:
-------------
Provide the --with-included-gettext argument to configure:
./configure --use-included-gettext
Use GNU gmake to build:
gmake

View File

@ -1,82 +0,0 @@
/** \page rawnotes Miscellaneous Notes.
\section stock splits & cost basis
OK, here's a question for accountants of various different countries:
What's the cost basis for a stock split? Does the rest of the world do
it the way the US does it?
For example:
In Jan 1995 buy 100s stock for $10 per share
In July 1997 split 2-for-1
In August 1997, sell 120s stock for $30 per share
I believe the following is correct for the united states:
My cost basis is $5 per share, and my gains of $25x120 are taxable
as long-term cap gains.
--- would there ever be a case where the cost basis should be $10 for
the first 100 shares, and $0 for the remainder?
--- would there ever be a case where the gains would be considered
'short-term' for some portion of the total?
\subsection Spin off stocks.
OK, that was easy. Here's the harder one: a spin-off:
For example:
In Jan 1995 buy 100s of stock A for $10 per share
In July 1997 receive 1s of stock B for every 20s of stock A.
Stock B is new, and will trade under its own new ticker symbol
as of the date of this split.
-- What's my cost basis for B? is it $0.000 ?
-- What's my cost basis for A? is it $10, or something else?
-- Are these questions supposed to be answered by company A,
or do I just 'guess'?
Note there is still an invariant:
(old price of A) * 20s == (new price of A) *20s + (price of B) * 1s
\section Depreciation, Sinking Funds ...
On 21 Apr 2000 20:39:43 CDT, the world broke into rejoicing as
John Hasler <john@dhh.gt.org> said:
\verbatim
> Lauren writes:
> > I'm not familliar with sinking funds, but what makes them a bit different
> > from a book entry like depreciation (also somewhat virtual) is that they
> > are happening with real accounts that need to be reconciled against an
> > outside statement.
>
> I don't see that. While the purpose of a sinking fund may be to pay off
> some bonds in ten years and there may even exist a legal obligation to have
> it, the funds being transferred to it now have nothing to do with any
> outside statement.
>
> A sinking fund to pay off some bonds is pretty much the same thing as
> saving up to pay off the balloon payment on the morgage.
>
> When you transfer funds to your "Savings Goal" or your "Sinking Fund" you
> are transferring funds from one asset account to another. Just credit
> 'Cash' and debit 'Savings Goals:Honeymoon'.
\endvarbatim
The problem with proceeding to credit Cash and debit "Savings Goal" is
that this invalidates any reconciliation of Cash. I'd be game to do
this if I credited not Cash, but rather "Cash:Goals", a subaccount of
Cash that can be ignored when it needs to be,
For different purposes, I will want both to consider and ignore these
"funds reservations."
- When making up a <b>budget</b>, I care about what funds are reserved for
particular purposes.
- When trying to figure out if my bank account is going to be
overdrawn, "reserved" funds are <b>irrelevant.</b>
I would thus suggest that the "gentle user" use the budget system to
manage this rather than having these be "true" transactions in the
ledger.
*/