Thank you for your feedback, François. We have now put the port in Git (https://github.com/netsurf-plan9) and our changes should all be in the branch 'plan9'. We are next about to rebase our branches onto 'head' instead.
> Does it require C89 style (like, variables declared at beginning of block)?
The compilers in 9front has partial C99 support, including support for variable declaration anywhere in the block, and we'd consider adding needed features for better compliance, if needed.
If to merge the Plan 9 port into the upstream later, maybe a solution would be to have a 'mkfile' fragment that lists sources, one per line. That could be included by both gmake and mk:
-- mkfile --
OFILES=`{<files grep '\.c$' | sed 's/c$/$O/g'}
-- gmake --
DIR_SOURCES=$(shell cat files)
The main things we had to do to compile:
* libwapcaplet has macros that uses GNU extensions, that would require 'statement expression' support in the compiler. Maybe these functions could be made 'static inline' instead, as is used in other places.
* copied a number of auto generated files from a Linux build, generated by Perl, Python, Flex & Bison. We'll need to update 'ports' (our imported tools and libraries) if we want a fully native build, that's on us. Haven't tried the available ports of Perl & Python in Plan 9, but the .l and .y didn't work with the original Lex and Yacc.
* we need C99 macro varargs, (...) and __VA_ARGS__, instead of the non-standard GCC macro varargs (...args).
* our compiler currently doesn't support bitfields in static initialisers. We'd like to fix this eventually, but for now we just changed bitfields to shorts and integers.
* we don't have support for variable length arrays (VLA) on the stack (e.g. widths[][] and heights[][] in netsurf/desktop/frames.c)
Lastly, here is a video clip showing how downloading and running looks now: https://hvplay.hv.se/media/t/0_xbq4r8ed (7 min)
Jonas
On 8 January 2020 at 17:52:07 +02:00, François Revol <revol@free.fr> wrote:
Hi Jonas,Le 06/01/2020 à 16:38, Jonas a écrit :Dear Netsurf developers,I have started a port of Netsurf 3.9 to the operating system Plan 9frontend for now, but I plan to continue with a native frontend, alsopossibly with help from other developers.Wow, nice to see NS ported to yet another platform :-)quality of the Netsurf source. Another obstacle is that most larger GNUdevelopment tools aren't available for Plan 9, no GCC for example. Plan9 has its own C compiler (https://9p.io/sys/doc/compiler.html) thatsometimes does things in different ways, and typically doesn't supportGCC extensions and newer features added to the language lately.Does it require C89 style (like, variables declared at beginning of block)?For the Haiku ports I tried to maintain C89 code for a while for GCC2.95, and if another platform requires it that'd be an incentive to fixreplicant support so we could put NS as a widget on the desktop…In the absence of GCC/Autotools/GNUmake and friends, I have written myown build system using Plan 9 'mk' (using 'mkfile'). I am aware thatthis makes a possible upstream integration of the port harder.Well we don't use autotools anyway, we have custom makefiles used as abuildsystem for all libraries:Maybe it's possible to isolate the incompatible parts from it andreimplement them for other make engines?I once managed to write a simple makefile engine for both GNU make andMS Nmake that accepted unchanged makefiles with only declarative stuff:Alternative routes would have been making GCC work on plan 9---some workhas been done on this (https://harvey-os.org), or to try to generateplan 9 binaries from Linux using cross compilation. Both ways would be alot of compiler development work, and I am quite sure that the plan 9Well for continuous integration we might want to do that anyway. But ifyou went this far without changing code it can probably be fixed.I started with the source tree of Netsurf 3.9, downloading all allsupport libraries separately (that is why they have version numbers inthe directories). I have not deleted any files, only added files andchanged files. All files 'xxx.y' that I changed are backed up as'orig_xxx.y' making it easier to 'diff' against the original. I got thetip that it might be a good idea to make a clone of the official Gitrepository and applying the diffs against it, in which case the 'orig_'files won't be necessary, and a possible merger maybe easier to do inIndeed, it's usually better to work on the HEAD. And with git you canrebase your changes from time to time, with git resolving most of theconflicts itself.I believe you should already have a git client:It might also be possible to build some simple client like this oneusing libgit2:François.
No comments:
Post a Comment