On Tue, Jul 26, 2016 at 8:57 PM, Albert van der Horst wrote:
Do you really demand that a Debian package can generate windows
executables, and booting floppies in double density?
We already have tested and working GCC cross-compilers for Windows.
https://packages.debian.org/search?keywords=mingw
I don't think Debian supports floppies at this point.
I don't tweak the assembler myself (maybe for a test). Others may, it
is a
service saving them the considerable time to understand a complicated
system
in case they want something simple. Also (in contrast to gforth) it is
assembler all the way down, but some of it is an assembler
representation of
Forth code.
...
Let's start with the data. The knowledge to do 64 bits is contained in
width64.m4 , there is also width32.m4 and width16.m4. The knowledge to
do
nasm files is contained in nasm.m4. Other assemblers have their
m4's.Last
but not least linux.m4 versus msdos32.m4 versus osx.m4 versus
alonehd.m4
etc. So we have orthogonal sets of alternatives. Now these are
selected by
configuration files, also interpreted by m4. Configuration files also
contain choices (e.g. "prepared for multitasking") and sizes. A
prelude sets
defaults, changeable by the configuration file. A postlude makes
depending
configurations and detects conflicts. (Real mode -> 16 bits. Real mode
and
32 bits --> error).
A configuration item is an m4 function.
Then there is one generic file. Parts of it are protected by a m4
function
that decides whether or not it will show up in the output.
A configuration file, an assembler selection and the generic file are
passed through m4, to generate an assembler source, a test file, and
the
glossary documentation.
(So all documentation is pertinent. It says "a cell size is 64 bits"
"you
have 8 slots in the search order").
The glossary documentation is sorted by my sssort tool that can
specify
records by regular expressions, then combined with the other
information
that also passes through m4. texinfo takes it from there.
With all that in place development workflow is trivial:
I can add one test line in the generic file, change the name of
command >IN
to PP, or change the section where a command belongs, increase the
size
allocated to stacks etc. , and go make stuff, up and including fitting
documentation.
...
You're awfully optimistic here. That is hardly more than a list of the
files
involved. The document is called cifgen.ps and is generated via the
makefile. It can be downloaded separately:
http://home.hccnet.nl/a.w.m.van.der.horst/cifgenps.zip
That is a lot to digest, thanks for the comprehensive explanation.
FYI, we have nasm in Debian too:
https://packages.debian.org/nasm
If you place the source* into a public version control system and
create release tarballs from those, that satisfies Debian's
requirements.
*ci86.gnr, the *.m4 files, the *.cfg files, the make files and any
other generic source files I have forgotten.
Please also release the source code for ssort somewhere, either as
part of ciforth or if you are developing it as a separate project, in
a separate git/cvs repository. The current release tarball for ssort
only has an ELF binary, which I assume is not the source for it.
In addition, I would recommend that any Debian packaging *always*
rebuild all automatically generated files (including the .asm files),
by removing them at the beginning of the `debian/rules build` stage of
the build and relying on the upstream build system to regenerate them.
This means that the Debian build process proves that Debian (and our
users etc) has the ability to build from source.
I'm more interested in recommendations of Debian developpers than
those
of wiki. Surely you have by now an opinion what would be preferably
for Debian.
I myself use Alioth, Savannah, SourceForge, GitHub and LaunchPad for
different projects. There are no hosting facilities that I personally
like, mostly because they are all web services. Debian itself uses
FusionForge on alioth.d.o, but that is for Debian related projects
rather than upstream development. World-wide, GitHub is relatively new
and the most popular, but it is a proprietary, for-profit service.
Debian folks tend to use Alioth or Github.
Then there is history. There are over a thousands meticulously
documented
versions of ci86.gnr and a couple of dozen tagged versions.
If I must leave that behind, some convincing need to be done.
I certainly would not recommend dropping the history.
The options here are to host the CVS repository publicly or
to convert the CVS repository to a git repository:
https://git-scm.com/docs/git-cvsimport
https://www.kernel.org/pub/software/scm/git/docs/gitcvs-migration.html
http://cvs2svn.tigris.org/cvs2git.html
https://github.com/BartMassey/parsecvs