Fwd: Re: Preliminary questions for sponsoring a compiler
I didn't mean to put this off list, my bad.
-------- Oorspronkelijke bericht --------
Onderwerp: Re: Preliminary questions for sponsoring a compiler
Datum: 2016-07-25 15:58
Afzender: Albert van der Horst <albert@spenarnc.xs4all.nl>
Ontvanger: Paul Wise <pabs@debian.org>
Paul Wise schreef op 2016-07-25 15:12:
On Mon, Jul 25, 2016 at 8:51 PM, Albert van der Horst wrote:
Question 1: Am I obliged to supply a .s file and linking prescripts?
You need to supply the upstream source code and build system. If those
are the upstream source code and build system, then yes.
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.
The assembler files are merely intermediate files here. From there
it is smooth sailing, a build is a one-liner.
(Because fasm is not in main)
fasm is in main:
https://tracker.debian.org/pkg/fasm
The problem is: ld is not stable w.r.t. linking pure assembler files.
That is a shame because fasm is limited to x86 architectures. If there
are alternative tools that can be used to build lina then that would
be a good idea.
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?
So my conclusion is that I'll supply a public build system and keep the
remainder private.
I could supply an assembler file that can be build using the build-in
assembler of lina. Does that count as "not require a package outside
of main
for compilation", the situation being about the same like the GNU
c-compiler?
That counts as suitable for main, as long as it is not pre-built.
The GNU c-compiler is prebuilt, in order to compile main. Likewise I
can only build lina with lina if I supply a prebuilt lina.
So I interpret that as no, the GNU c-compiler has a monopoly to the
prebuilt case.
<SNIP>
Question 2: Are there any mentors that would even consider a compiler
that
is in competition with GCC, rather than a second generation compiler
like
Python Perl and the rest, that depend on GCC? Irrespective of merits?
(On the upside, dear mentor, this will be some of the simplest
packages you
will ever encounter. ).
There are people who will sponsor any package that is suitable for
Debian. Finding someone to create the package in the first place is
harder than finding a sponsor at this point in time. The package
maintainer could be you though.
I understand now that there must be a maintainer and a sponsor.
I would gladly be the maintainer of the package, but I thought that
makes me one of the debian developers, an elite group with
restricted membership? How do I apply? Also I'll need a lot of help.
Yes, I know there is an official GNU Forth compiler gforth. An
important
difference is that a package built with lina requires lina for
building only, not for running. An alternative build with lina for
e.g.
``factor'' 2] is as simple as the factor build in C, one executable,
one
man-page.
That seems like a reasonable reason to package lina.
Glad that you understand the argument, that I honestly think to be
valid.
Groetjes Albert
--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst
Reply to: