LCDproc development and user support list

Text archives Help


[Lcdproc] lcdproc (client) completely ported to NetBSD.


Chronological Thread 
  • From: gfk AT logidac.com (Guillaume Filion)
  • Subject: [Lcdproc] lcdproc (client) completely ported to NetBSD.
  • Date: Thu Aug 14 23:57:01 2003

Le Jeudi, 14 ao=FBt 2003, =E0 06:25 America/Montreal, Thomas Runge a =
=E9crit :
> On Wed, 13 Aug 2003, Guillaume Filion wrote:
>> I'd like to know how you plan for file naming. One way of doing it=20
>> that
>> comes to mind is something like batt-netbsd.h and batt-linux.h and=20
>> have
>> a batt.h including the right one. I can see one problem with this way
>> of doing things, if for example macosx and freebsd use the same API=20=

>> for
>> battery, do we make two identical files names batt-freebsd.h and
>> batt-macosx.h, use one file named batt-freebsd-macsox.h, use
>> batt-freebsd.h or something else?
>
> No, a header is a contract about the interface. And the interface
> must be the same for all platforms, it's just the implementation
> that is different. So we will have something like batt.h and batt.c
> that contains machine independent (MI) code (protocol handling etc.)
> and one machine dependent (MD) file per supported OS which includes
> all functions to get the statistics/values (lets call it
> foo_<uname -s>.c). In addition there is a foo.h that defines the
> MD functions (gets included by batt.c and MI friends). The
> Makefile does the magic of only compiling the relevant
> foo_<uname -s>.c file, possibly doing some magic by calling the
> systems uname(1), assigning it to a variable and using that for
> further processing.
>
> If we have multiple OS's with the same interface, I'd simply copy
> the file and use that. The interface of one OS might change in the
> future, while the other stays the same or develops into another
> direction. It's easy for the port maintainers to keep in sync.
> Hmm, maybe we should assign names to the ports to the different
> OS's, so we have a central point to send requests, suggestions
> and/or complains.

That sounds good. However I'd like to have the server stay the way it=20
is, that is autoconf style feature testing. There is not a lot of MD=20
code in the server code.

> As I was complaining about the current status for years (in the
> beginning louder, resigning later), I'd volunteer to do the changes.
> But keep in mind, that I have access to NetBSD boxes only. I need
> a calm tester with some spare time for every other supported OS
> or an account on such machine.
>
> Thank you. :-)

My pleasure! I'm quite happy that you'll be working on the code; I=20
spent numerous hours trying to make your old patch work with the CVS=20
version. As for the testing, sourceforge used to have a FreeBSD box in=20=

the compile farm, but they removed it to replace it with yet another=20
Linux. A compile farm with only Linux is not very usefull. 8( I don't=20
have a FreeBSD or OpenBSD box here but I guess/hope someone on this=20
list will.

So is there a charitable soul that could give Thomas an account on a=20
FreeBSD and/or OpenBSD box?

Oh and BTW, you'll need an account on sourceforge to have CVS write=20
access.

Best,
GFK's
--=20
Guillaume Filion
Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/
PGP Key and more: http://guillaume.filion.org/





Archive powered by MHonArc 2.6.18.

Top of page