Re: Preliminary questions for sponsoring a compiler
* Paul Wise, 2016-07-30, 15:16: 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. There are many command-line tools that let you distance yourself from the webby nature of GitHub. This is what I use: cligh git-hub github-backup grip https://github.com/c4milo/github-release https://github.com/jwilk/github-editmeta -- Jakub Wilk
Re: Fwd: Re: Preliminary questions for sponsoring a compiler
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
Re: Fwd: Re: Preliminary questions for sponsoring a compiler
Paul Wise schreef op 2016-07-26 07:15: On Tue, Jul 26, 2016 at 3:01 AM, Albert van der Horst wrote: 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 Wrong! Must be: http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html I doubt that any one has downloaded this in a dozen years ;-( . I see. 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. There is a difference between "I can modify this" and "Open Source". After all, it is possible to modify ELF binaries with a hex editor, objdump or IDA Pro. It is possible to modify minified JavaScript using a text editor. That doesn't make individual ELF files or minified JavaScript files "source". The important thing is equality of access to the work between upstream developers, Debian package maintainers, Debian users, users of Debian derivatives and every other person touching the software in some way. I have included here some links to articles about what "source" or the "preferred form for modification" is: http://www.inventati.org/frx/essays/softfrdm/whatissource.html https://b.mtjm.eu/source-code-data-fonts-free-distros.html https://wiki.freedesktop.org/www/Games/Upstream/#source As an experienced developer I'm familiar with this. In the end it is about knowledge. The comments in my Forth solutions to the projecteuler.net problems are worth more than the code itself. If compilers cease to exist for a language x, the source code is what left and represents the knowledge. I hear you, but consider this. Given the choice to compile c or patch an ELF file, I ( still ;-) ) prefer modifying the c-source. There is a forth loosely based on ciforth : jonesforth. Given the choice between using the generic system and using the assembler source, Mr. Jones chose the assembler source. I should have used the word separate, not private. Ah, that is fine, as long as both are packaged for Debian and appropriate build and runtime dependencies declared. Do you really demand that a Debian package can generate windows executables, and booting floppies in double density? And do you demand to test that to a level approaching Debians (let alone mine) quality standards? It sounds like you are automatically generating some assembler from forth code and then hand-tweaking the assembler? 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. Could you explain the development workflow here? 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. 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. I assume you are talking about README.ciforth here? 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:
Re: Fwd: Re: Preliminary questions for sponsoring a compiler
On Tue, Jul 26, 2016 at 3:01 AM, Albert van der Horst wrote: > 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 ;-( . I see. > 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. There is a difference between "I can modify this" and "Open Source". After all, it is possible to modify ELF binaries with a hex editor, objdump or IDA Pro. It is possible to modify minified JavaScript using a text editor. That doesn't make individual ELF files or minified JavaScript files "source". The important thing is equality of access to the work between upstream developers, Debian package maintainers, Debian users, users of Debian derivatives and every other person touching the software in some way. I have included here some links to articles about what "source" or the "preferred form for modification" is: http://www.inventati.org/frx/essays/softfrdm/whatissource.html https://b.mtjm.eu/source-code-data-fonts-free-distros.html https://wiki.freedesktop.org/www/Games/Upstream/#source > I should have used the word separate, not private. Ah, that is fine, as long as both are packaged for Debian and appropriate build and runtime dependencies declared. > 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.) Hmm, that sounds more complicated than what I am used to: a "source" form of the work in the upstream tarball and files automatically generated from that in the Debian binary package. It sounds like you are automatically generating some assembler from forth code and then hand-tweaking the assembler? Could you explain the development workflow here? > 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. I assume you are talking about README.ciforth here? > 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) That sounds suboptimal indeed. > 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. I would suggest switching to the git VCS and a public Free Software hosting service. git is much more popular than CVS these days and existing hosting services are less likely to go down if you stop working on this project for some reason. https://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities -- bye, pabs https://wiki.debian.org/PaulWise
Re: Preliminary questions for sponsoring a compiler
On 07/25/2016 09:28 PM, Albert van der Horst wrote: > Christian Seiler schreef op 2016-07-25 18:14: >> I don't quite get what you mean, I never had any problem with >> that. > > {Probably going off topic here] > A pure assembler file means full control over section names, their > properties (in particular, readable, writable *and* executable) and > where they are located. My compilation feature requires a stable > layout for the ELF header. Ah, ok, I didn't know you'd want that much control. Personally I tend to rely on relocations and ld resolving stuff for me, so I don't really care about the detailed ELF file layout, even when using assembler. But if that doesn't fit your use case, then yeah, GNU ld is probably not what you want. > By the way write.s gives me `` bad register name `%rax' '' Well, then your gcc is probably not x86_64 by default. ;-) Since assembler is different for every processor, I just took the most obvious architecture I know. Regards, Christian
Re: Preliminary questions for sponsoring a compiler
Christian Seiler schreef op 2016-07-25 18:14: On 07/25/2016 02:51 PM, Albert van der Horst wrote: The problem is: ld is not stable w.r.t. linking pure assembler files. How so? $ cat write.s .text .global _start .type _start, @function _start: mov $1, %rax mov %rax, %rdi lea str, %rsi mov strsize, %rdx syscall xor %rdi, %rdi mov $60, %rax syscall .data str: .string "Hello World!\n" strsize: .quad .-str $ gcc -Wall -c -o write.o write.s && ld -o write write.o $ ./write Hello World! $ strace ./write execve("./write", ["./write"], [/* 58 vars */]) = 0 write(1, "Hello World!\n\0", 14Hello World! )= 14 _exit(0)= ? +++ exited with 0 +++ $ cat write-nasm.s section .text global _start _start: mov rax, 0x1 mov rdi, rax lea rsi, [hello] mov rdx, length syscall xor edi, edi mov rax, 60 syscall section .data hello db 'Hello World!', 10, 0 length equ $ - hello $ nasm -f elf64 -o write-nasm.o write-nasm.s $ ld -o write-nasm write-nasm.o $ ./write-nasm Hello World! $ strace ./write-nasm execve("./write-nasm", ["./write-nasm"], [/* 58 vars */]) = 0 write(1, "Hello World!\n\0", 14Hello World! )= 14 _exit(0)= ? +++ exited with 0 +++ I don't quite get what you mean, I never had any problem with that. {Probably going off topic here] A pure assembler file means full control over section names, their properties (in particular, readable, writable *and* executable) and where they are located. My compilation feature requires a stable layout for the ELF header. gcc and ld are intended for c and if you try to do the things I want, it feels like remote controlling a robot that must drive a car. I will not bore you with all the details. One detail, .text and .data have predefined properties. Now look how many options ld has. One is appropriate called -nmagic . It sometimes helps to turn those properties around, at other times it failed. By the way write.s gives me `` bad register name `%rax' '' Regards, Christian Groetjes Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
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 <p...@debian.org> Ontvanger: Albert van der Horst <alb...@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
Re: Preliminary questions for sponsoring a compiler
On 07/25/2016 02:51 PM, Albert van der Horst wrote: > The problem is: ld is not stable w.r.t. linking pure assembler files. How so? $ cat write.s .text .global _start .type _start, @function _start: mov $1, %rax mov %rax, %rdi lea str, %rsi mov strsize, %rdx syscall xor %rdi, %rdi mov $60, %rax syscall .data str: .string "Hello World!\n" strsize: .quad .-str $ gcc -Wall -c -o write.o write.s && ld -o write write.o $ ./write Hello World! $ strace ./write execve("./write", ["./write"], [/* 58 vars */]) = 0 write(1, "Hello World!\n\0", 14Hello World! )= 14 _exit(0)= ? +++ exited with 0 +++ $ cat write-nasm.s section .text global _start _start: mov rax, 0x1 mov rdi, rax lea rsi, [hello] mov rdx, length syscall xor edi, edi mov rax, 60 syscall section .data hello db 'Hello World!', 10, 0 length equ $ - hello $ nasm -f elf64 -o write-nasm.o write-nasm.s $ ld -o write-nasm write-nasm.o $ ./write-nasm Hello World! $ strace ./write-nasm execve("./write-nasm", ["./write-nasm"], [/* 58 vars */]) = 0 write(1, "Hello World!\n\0", 14Hello World! )= 14 _exit(0)= ? +++ exited with 0 +++ I don't quite get what you mean, I never had any problem with that. Regards, Christian
Fwd: Re: Preliminary questions for sponsoring a compiler
Oorspronkelijke bericht Onderwerp: Re: Preliminary questions for sponsoring a compiler Datum: 2016-07-25 16:15 Afzender: Paul Wise <p...@debian.org> Ontvanger: Albert van der Horst <alb...@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. 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. 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. 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 and build system into a public project and VCS. 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. No, the GNU c-compiler source code tarball does not contain a pre-built copy of itself. I guess it does require itself to build though, which is fine but different to containing a built copy of itself. 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. 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 -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst signature.asc Description: PGP signature
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 <alb...@spenarnc.xs4all.nl> Ontvanger: Paul Wise <p...@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. 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
Re: Preliminary questions for sponsoring a compiler
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. > (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. > Or is it sufficient to supply .s and let the builder figure out > how to make an executable? 1] Our building is automatic and based on the upstream build system. > 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. > If I got a sponsor, I need only supply an upstream package and the sponsor > takes care of the rest? He will prompt me for any changes to be made in > order to comply? The Debian package maintainer takes the upstream code and build system and wraps it such that the standard debian/rules targets are mapped to upstream build system targets. Who the package maintainer is depends on who has the interest, time and skills to create the packaging. Any package maintainer should maintain a good relationship with upstream, passing patches and bugs etc to them. > 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. > 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. -- bye, pabs https://wiki.debian.org/PaulWise
Preliminary questions for sponsoring a compiler
Dear mentors, Since 2002 lina is a stable Forth compiler under x86 linux (And compatible compilers available for OSX, win32 ). From the beginning it has been fully documented using texinfo, plus a man-page, that documents the options and a judicious excerpt. lina page http://home.hccnet.nl/a.w.m.van.der.horst/lina.html Tutorial https://forth.hcc.nl/w/Ciforth/Ciforth?setlang=en Now I'm planning to supply some actually useful packages as .deb in debian made with this compiler. (In fact flashers for microcontrollers in behalf of i.a. http://home.hccnet.nl/anij/nof/noforth.html) The first thing is probably find a mentor for lina itself. The compiler is hardly mainstream: 1. It is written in assembler. 2. It is at the same time an interactive system, a scripter and a compiler. 3. It is totally self contained, doesn't link to any library. 4. It has its own library, but that is a source library. 5. It uses the library and the executable for configuration, no shell variables. You configure it by copying bin+lib to a project directory and change those (and yes,they are small). Making it is simple: fasm lina64.fas lina64 I aspire lina to be in main of debian. I see the guidelines: " For the mainsection, Debian Policy requires it to be fully compliant with the Debian Free Software Guidelines(DFSG(http://www.debian.org/social_contract#guidelines ) ) and not to require a package outside of main for compilation or execution. This is the desired case. " Not so simple is building it with gas, and ld. Question 1: Am I obliged to supply a .s file and linking prescripts? (Because fasm is not in main) The problem is: ld is not stable w.r.t. linking pure assembler files. Or is it sufficient to supply .s and let the builder figure out how to make an executable? 1] 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? OR: If I got a sponsor, I need only supply an upstream package and the sponsor takes care of the rest? He will prompt me for any changes to be made in order to comply? 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. ). For those who wonder: 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. lina scripts have been proposed in a webserver. A sub ms startup time makes some applications practical. http://lina.minimaltype.com Groetjes Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst 1] My actual build system is assembler-blind, and word-size agnostic so no sweat for gas, nasm or fas formats that are actually intermediate files. 2] -~ $ cat factor.frt WANT SQRT : main 1 ARG[] EVALUATE DUP . ": " TYPE DUP SQRT 1+ 2 DO BEGIN DUP I MOD 0= WHILE I . I / REPEAT LOOP . CR ; ~$ lina -c factor.frt ~$ time ./factor 111 111 : 3 37 real0m0.001s user0m0.000s sys 0m0.000s -