Re: Can't compile SWI on FreeBSD

Darren Bane <darren.bane@xxxxxxxxx> wrote:
Jan Wielemaker wrote:
!snip!
If anyone knows the proper way to do this, please let me know.
Your Mac OS X workaround doesn't work for 10.3, so I raised
https://svn.macosforge.org/projects/macports/ticket/10334 FreeBSD
could be the same given their common ancestry.

This may be a long story, but hold on for the point. :)

I like to keep the approx 20,0000 packages from sourceforge upt-o-date on
my little network. Various hardware, various platforms.

This is difficult to do with a staff of 3, so we've developed some
automated programming tools to upload stuff every week or 2, "debug" it,
and install it.

The "debugging" is 99.9% automated. It's nice to have a base of 20,000
packages to datamine for common problems, or develop contrasts for
common solutions. We also rely on released s/w being "close" to working,
and only a small edit away from "success". :)

But since this in the realm of AI, the solutions developed by the process
don't always "work [as intended]", or "work well", or "look nice".

In the case of packages declaring stuff that is already declared in
a slightly different and probably non-conforming way in some system header
the potted solution the tool has developed over a few years of its
automated musing and tinkering runs along the lines of:

#define offendingname foobar
#include <systemheader>
// package version of the offending name:
sometype offendingname(someparams);

If necessary it can include some ifdef's to ensure things are identical
on the original platform, viz:


#ifdef __FreeBSD__
#if OSVERSION == something
#define offendingname foobar
#endif
#endif
#include <systemheader>
// package version of the offending name:
sometype offendingname(someparams);

It's quick and painless, and usually results in no further compiler warning
(or error).

Like all AI techniques, it can't really be viewed just after breakfast.
.

Relevant Pages