FreeBSD specific Release Engineering

scripts using sh instead of bash

(originally by Andres K. Foerster)

Current scripts: samplecfg/install.sh/cross* known scripts not affected: makepack (no chance of running on a TARGET computer)

The script sometimes uses one "=" and sometimes two "==" for comparisions. The /bin/sh of FreeBSD accepts just one "=" in comparisions. See test(1). or sometimes the "x" trick works: if [ "x$something" = "xsomething" ] ...

"echo -n" is supported in the shell of FreeBSD, but it's not standard. You could use "printf" instead of "echo -n". That seems more standardized.

Also the tar parameter "--directory" is a extension of GNU-tar. You could use "-C" instead of "--directory", but be careful with that. It seems "-C" is implemented differently. (My FreeBSD still comes with GNU tar, but I've heard that they switch to their own version of tar... I'll have a look at it.)

That's all as far as I can see. Then you can use "#!/bin/sh".

(Marco van de Voort:)

• Also test using BSD sed and tar from time to time. (some sed constructs are already replaced by awk)
• In case of bash use #!/usr/bin/env bash NEVER hardcode the shell path!

GTK problem with newer ports

FreeBSD ports decided to rename the gtk 1.x ports from gtk12 to gtk-1.2. (and similarly for gdk and glib). There was a note about this in the ports tree docs in Nov 2005, but we found out somewhere in februari when bugreports started to trickly in. There was no grace period between the note and the breakage.

Anyway, there are several problems at once here:

• the "recommended" way; using gtk-config, relies a lot on C/gcc specific subsystems way of doing things. (e.g. it emits gcc commandline parameters) It works for them because release engineers of a distribution prepare and test the whole process. This is not doable for us, and would only add a major fragile complication to solve a minor one.
• This is aggrevated by a problem in FPC. Library names are hardcoded in source, and end up hardcoded in precompiled files. IOW one can not influence linking of a FPC program with gtk without recompiling fpc. A good solution still has to be found. Some options:
  • some want a complicated packaging system aka CPAN
  • some want to dl_open all libraries, and add compiler support to ease this. This can be easily done using lazy linking. You need to get pic working on FreeBSD, set the library name to '', compile the gtk units with pic and dl_open the gtk libs at runtime. Don't expect to get this working out of the box, but it looks doable.
  • A somewhat more modest and short term approach would be a simple substitution problem that would tackle a large percentage of the errors. Library names in source can be mapped to other names. Multiple libs even. This could be seeded by a simple gtk-config test compile. The main advantage is that a breakage on gtk-config (e.g. new version) doesn't break FPC hopelessly.
• A related problem is GTK2 programs requiring adaptations to the "main" program. I don't know the exact status of this problem.