Libraries and headers

[DrV]

As a user of FreeBASIC, I'd like to think about some ways to improve our current method of keeping libraries/headers up to date and including new ones.

Currently, there is not really any organization here. When somebody notices something is out of date, they can post something in the forums about it or try updating it themselves and making a patch or similar, but there are no good guidelines or ways to make sure headers get updated.

I see three main points that need to be addressed:

1. Updating existing headers
2. Adding headers for new libraries
3. Being compatible with multiple versions of a library

1. Updating existing headers

For this part, I envision some kind of web page with a list of all the libraries for which FB has translated headers and their versions. It would have some way to let end users poke an "Out of date" button that would mark it as needing an update (due to a new version of the library).

It could possibly also have a "Broken" button (for stuff missing or incorrect in existing headers), although this is probably better served by the bug tracker.

If we can translate some headers without any hand editing with SWIG, we should probably put the SWIG .i files somewhere central and add some way to automate the translation. This could even involve headers which can't be translated automatically, if SWIG is used for part of the translation, or notes about the manual translation process.

2. Adding headers for new libraries

This could be part of the web interface from the previous point ("Request new translation" button, perhaps); it could even possibly allow contributors to upload their attempts at translation, although this again is probably better suited to the existing tracker.

Here we also come into the problem of import and static libraries on Win32 and DOS. The import libraries are relatively large when taken as a group, and most users probably won't need most of them. Currently, we distribute all of the available import libraries in the FB installer. I think it would be best to separate the "core" libraries (the ones needed to build "pure FB" apps) from the other libraries and only include the "core" ones in the FB installer.

The best scenario (in my opinion, at least) would be for library developers to include the FreeBASIC translation of their headers in their own releases (and then the FB end user would install these releases with FB headers themselves when installing the libaries they are using, ensuring a consistent header version, etc.), but I don't see this happening for most libraries soon.

Otherwise, we could perhaps create an optional "3rd party libraries" installer or zip or whatever, or even have full and core-only FB installers. We could even split the 3rd party libraries into smaller categories, even to the level of one small download per package, but this probably creates too much work for end users unless some kind of automated downloader is written.

This also helps to decouple the versions of the headers (and probably the headers themselves) from FreeBASIC versions/releases (you should be able to upgrade to a new FB version without changing header/lib versions, or upgrade a particular library to a new version without upgrading FB).

3. Being compatible with multiple versions of a library

This has already bit fbc itself - libbfd, used internally in the compiler, commonly has interface-breaking changes across releases, so new headers won't work with old versions of the library, and vice versa. libbfd is surely not the only example of this; some library authors are careful to maintain backwards compatibility, but some aren't, and we have to deal with those cases somehow. The best way, as I already said in the previous point, is to let the library authors manage the FreeBASIC translations of their headers and include them with their releases. This would work best on Linux and similar OSes with a central package-management system - the user would install a library the normal way with a package manager, and the FreeBASIC headers for the installed version would magically show up in the right place.

Barring library authors distributing headers themselves, I think the best option is for FB to distribute the latest version of each header, and then have an easily accessible archive of older versions. This is far from ideal and pretty error- and work-prone (the impetus is on the FB user to figure out what version of each library he has and to get the proper version from the archive), but it's better than the current "you only get whatever random version of the header we have" situation.


Any comments, better ideas, or other concerns are welcome!

[Mentat]

What about a small batch file to house clean? So the user passes the file name, and then it is sent to the include file, or the lib file. Or pass a release of a new update of header files and replace the old ones?

[jofers]

As someone with web experience who occasionally translates headers, what can I do to help?

On the ideas side, I like the idea of an FB package system. You could keep a lot more headers on a server, and not have to distribute them with FB this way.

A command line utility could fetch it, or automatically be called by fbc when it can't find a header or static library: e.g. "fblibget Allegro".

[counting_pine]

Interesting timing - I've been looking through our headers today, because I found a couple that have errors - caca.bi and mini.bi. (I also found some errors in our image_compat.bi - I guess noone's been using that...)

I think I've fixed caca.bi - there was a sub declared as a function - but mini.bi is more difficult, since the lib has had several breaking changes made since the bi was made. The website has since moved, and its current source repository starts a few years after the header was translated.

Yeah, a web site might be a good idea. Each library should get its own section, providing a link to the library's web site, and header files. It would also be useful to have direct, or near-direct, links to downloads of the actual lib, so it's easy to use, and also easy to test. It might also good to put examples there too.

It might also be good to have information on using SWIG in the wiki. The more people we have with the ability to translate the headers, the better.

[DrV]

The mini header can just go away as far as I'm concerned (unless you've already fixed it up), as I translated that some years ago and never even used it myself (along with writing a small C wrapper in src/contrib), so unless somebody else is using it... :)

[Bunuel66]

Hi all.

Is ti a version of SWIG available for LINUX and configured for FREEBASIC?

Regards.

Luis

[spoken20]

I have many books in my house but I don't have library I get ten thousands books all around in 1 year but now I want to build a library what should be the header to follow the books into an order.

HAI GUISE, I'M A BIG HARIY SPAMMBOT LUL