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 -- bye, pabs https://wiki.debian.org/PaulWise
