Paul Wise schreef op 2016-07-30 09:16:
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
[Sorry for the long quote]
The generic system for ciforth is now present in github.
https://github.com/albertvanderhorst/ciforth
This is a complete copy of the rcs/cvs system with all versions,
logs and tags since 2000.
The latest releases for up to eight targets are in the subdirectory
release.
Relevant for Debian are the 32 and 64 bit linux versions.
Without examples and red tape a release is: (executable+library+doc)
lina32
forth.lab
lina.1
ci86.lina32.info
A source distribution would add
ci86.lina32.s or ci86.lina32.fas
ci86.lina32.texinfo
To be found in lina32-5.3.0.tar.gz
I would be happy to find a sponsor for lina32, which is a runtime
package
without dependancies. Building the package requires pdftex, texinfo and
gas.
I'm willing to invest in understanding the making of deb files
and maybe add that to the generic system.
In /release there is also a tar of version 5.0 of the generic system.
This contains some 60 of the ca. 200 files in the git archive, enough to
generate an assembler source file and documentation in correspondance
for
lina32 and more.
Despite the fact that the files are generated, I think they can be
counted as source, because all assembler lines in the .s correspond one
to one with lines in the generic file, with only adaptations to
accomodate the difference between gas and other assemblers, and leaving
out lines specific for e.g. MSDOS. It is unlike a c-source where a
generated assembler source would be essentially less empowering than the
c-source itself.
Groetjes Albert
1,0-1 Top
--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst