Libraries and headers

For other topics related to the FreeBASIC project or its community.
DrV
Site Admin
Posts: 2116
Joined: May 27, 2005 18:39
Location: Midwestern USA
Contact:

Libraries and headers

Postby DrV » Jun 25, 2008 20:15

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
Posts: 332
Joined: Oct 27, 2007 15:23
Location: NC, US
Contact:

Postby Mentat » Jun 25, 2008 20:55

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
Posts: 1525
Joined: May 27, 2005 17:18
Contact:

Postby jofers » Jun 25, 2008 21:43

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
Site Admin
Posts: 6245
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Postby counting_pine » Jun 25, 2008 21:52

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
Site Admin
Posts: 2116
Joined: May 27, 2005 18:39
Location: Midwestern USA
Contact:

Postby DrV » Jun 26, 2008 0:25

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
Posts: 76
Joined: May 19, 2006 19:56

SWIG

Postby Bunuel66 » Oct 18, 2008 23:05

Hi all.

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

Regards.

Luis
spoken20
Posts: 3
Joined: Oct 25, 2008 6:03
Location: cebu
Contact:

Postby spoken20 » Oct 25, 2008 6:06

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

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 9 guests