In our previous episode, Francisco Reyes said:
Show quoted text 8 lines
>> Also, when one uses instal.sh, how does one uninstall?
>
> Not in theory. In practice it amounts to
> - killing /usr/local/lib/fpc/ and /usr/local/share/fpc.
> (or only the relevant version you installed if you have multiples),
> - weeding out binaries in /usr/local/bin.
Any reason not to have an uninstall.sh?
Yes. Nobody made it. Moreover the install.sh doesn't save what files it stored, and what dirs were (partially?) created. It only decompresses archives, it has no clue what is in them.
And of course deletion is more dangerous than installation. A mistake in scripting and you might wipe /.
In particular install.sh could be changed to save the directories where it
was installed and then create the uninstall.sh.
That would unlink $PREFIX/bin since it stores binaries there. You really need to do it on a per file level :-)
Show quoted text 5 lines
> Florian did a few bits last week, to help me over the point where I got
> stuck. We are currently investigating what is the next step.
Would it make sense for a newbie to even try to look at buildfaq or should I
wait to see what the "next step" will be?.
Both. Wait as far as x86_64 is concerns, but familiarize yourself with the buildfaq as much as possible (crosscompile between linux and -64, and between linux and freebsd). This since even if it gets done, it will be rough the first months.
Is there a list, other than this, to keep track of the progress of the
FreeBSD AMD64 port?
No. For an update you can also ask on IRC.
Also, once the port is finished will it always be up to
the same level as the i386 version in FreeBSD?
That depends on your (plural, as in the future FreeBSD/x86_64 users) patches and bugreports. Too little interest might cause it to preliminary die.
Maintenance costs effort, and needs input. Interest seemed on the rise, so we gave it a go to do the initial work, but the longterm input and bugfixing need to come from users.
It is really demotivating if you notice a major bug when you are packaging release $X, and find out it was in the year old $X-1 release too, and nobody noticed. That's what happened to the 1.0.x NetBSD and OpenBSD ports.
Show quoted text 5 lines
> Note that once a port is done, it usually needs a lot of testing and fixing
> of all kinds of smaller libraries. It might not be directly up to the level
> of other platforms.
Do we have a regression test?
Yes, in directory tests/ in the FPC sources (might not be in release sources, but a snapshot surely has it). FreeBSD/x86_64 had 26 "run" errors last weekend. I found a bug in statfs, and will see how it runs tonight.
As soon as it can compile itself, I'll upload a snapshot. Next will be getting access to C libraries (linking to shared libs)