Re: Fwd: Re: Preliminary questions for sponsoring a compiler
Albert van der Horst schreef op 2016-07-25 18:00:
-------- Oorspronkelijke bericht --------
Onderwerp: Re: Preliminary questions for sponsoring a compiler
Datum: 2016-07-25 16:15
Afzender: Paul Wise <pabs@debian.org>
Ontvanger: Albert van der Horst <albert@spenarnc.xs4all.nl>
Not sure why you moved the discussion off-list, in Debian we prefer to
discuss things in public. Feel free to forward my reply to -mentors.
That was a mistake. Like you can see I forwarded it.
On Mon, 2016-07-25 at 15:58 +0200, Albert van der Horst wrote:
My (upstream) build system is complicated and sophisticated.
It generates booting, msdos, windows dpmi, windows 32, OSX, linux
compilers in 16 32 and 64 bit from the same source file, together
with
fitting documentation and tests. Hardly something to throw over the
> wall.
Sounds useful to publish to me.
It has been published, the generic system is GPL as well.
It is on the net since ages
http://home.hccnet.nl/a.w.m.van.der.horst/ciforth-5.0.tar.gz and
http://home.hccnet.nl/a.w.m.van.der.horst/cifgen.html
I doubt that any one has downloaded this in a dozen years ;-( .
The assembler files are merely intermediate files here.
Then they are not source code, not the preferred form for modification
and should not be included in the upstream VCS and tarballs.
Indeed not in VCS , but we should not be dogmatic about tarballs that
provide a source that is feasible to change, i.e. they are Open Source
in actual practice.
lina (for the moment) is limited to x86 architectures (32 and 64) as
well. ARM lina is under way, but the nature of lina requires
adaptation for each architecture anyway. Do you really mean there are
ways to build assembler projects that are agnostic of architecture?
I'm not sure about that, but there are certainly assemblers available
that run on multiple architectures. nasm for example.
So my conclusion is that I'll supply a public build system and keep
the remainder private.
That sounds very much not anything like open source software to me,
please put the entirety of your upstream source code
into a public project and VCS.
I should have used the word separate, not private.
Let us keep in mind why we want open source. The freedom to add e.g. an
``unsigned less than or equal comparison'' to lina is better served by
an assembler source. It is actually doable by a moderately skilled
assembler programmer. ( Compare this with tinkering with GNU c by the
way. I have once modified GNU c to change the calling convention
for 68000 assembler code. Not for the faint of heart.)
There is a document contained in ciforth-5.0.tar that discusses when you
want to modify at the assembler level, and when at the generic level.
It is useful to provide both.
This is partly based on experience. In the 70's Forth systems were
generated by existing Forth systems. This didn't spread well, and only
the high priest of Forth could generate a system. It was not until
the systems were translated to assembler source that were widely
understood and could be build by widely available tools, that lead to
the Forth boom in early personal computing.(The famous FIG-Forth)
I do want to have this system on a public VCS. It is now in CVS
on my private server. Any advice of how to move with the history
intact is welcome.
Perhaps this document will clear things up:
http://mentors.debian.net/intro-maintainers
As upstream, you may also want to take a look at this:
https://wiki.debian.org/UpstreamGuide
You will hear more after I have studied those.
--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst
Reply to: