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(a)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 9
> > (<
http://9front.org>, <
https://9p.io/plan9).> It uses the
framebuffer
> > frontend for now, but I plan to continue with a native frontend, also
> > possibly 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 GNU
> > development tools aren't available for Plan 9, no GCC for example. Plan
> > 9 has its own C compiler (<
https://9p.io/sys/doc/compiler.html)> that
> > sometimes does things in different ways, and typically doesn't support
> > GCC 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 GCC
> 2.95, and if another platform requires it that'd be an incentive to fix
> replicant support so we could put NS as a widget on the desktop…
>
>
> > In the absence of GCC/Autotools/GNUmake and friends, I have written my
> > own build system using Plan 9 'mk' (using 'mkfile'). I am aware
that
> > this makes a possible upstream integration of the port harder.
> >
> Well we don't use autotools anyway, we have custom makefiles used as a
> buildsystem for all libraries:
> <
http://git.netsurf-browser.org/buildsystem.git/>
>
> Maybe it's possible to isolate the incompatible parts from it and
> reimplement them for other make engines?
>
> I once managed to write a simple makefile engine for both GNU make and
> MS Nmake that accepted unchanged makefiles with only declarative stuff:
>
<
http://miniserve.defence-force.org/svn/users/mmu_man/sdk-makefile-engine/...
>
>
> > Alternative routes would have been making GCC work on plan 9---some work
> > has been done on this (<
https://harvey-os.org>), or to try to generate
> > plan 9 binaries from Linux using cross compilation. Both ways would be a
> > lot of compiler development work, and I am quite sure that the plan 9
> >
> Well for continuous integration we might want to do that anyway. But if
> you went this far without changing code it can probably be fixed.
>
>
> > I started with the source tree of Netsurf 3.9, downloading all all
> > support libraries separately (that is why they have version numbers in
> > the directories). I have not deleted any files, only added files and
> > changed 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 the
> > tip that it might be a good idea to make a clone of the official Git
> > repository and applying the diffs against it, in which case the 'orig_'
> > files won't be necessary, and a possible merger maybe easier to do in
> >
>
> Indeed, it's usually better to work on the HEAD. And with git you can
> rebase your changes from time to time, with git resolving most of the
> conflicts itself.
>
> I believe you should already have a git client:
> <
https://hub.packtpub.com/introducing-git-fs-a-native-git-client-for-plan-...
>
> It might also be possible to build some simple client like this one
> using libgit2:
> <
https://github.com/sba1/simplegit>
>
>
> François.
>