Hi, [I'm not subscribed to the list, so sorry for the off-thread reply.]
> I find it pretty frustrating, as I have spent a fair about of time,
> and a serious amount of effort porting the code to Solaris 8 on
> X86 hardware, using the Sun compiler. I found many instances in
> the code that are dependant on the GNU compilers,
Point them out, point them out!
> and had to make a lot of changes in order to get the code to compile,
> so it certainly wasn't just a trivial recompile.
Unless you contribute a (unified) diff of your changes, those problems
won't disappear anytime soon.
> It's a real shame that people are using GNU-specific extentions
> in the code, since it breaks the code for anyone without the GNU
> compilers, or who are unwilling or unable to install the gcc/g++.
Is it possible, that you talk about C99 features and not GNU C
specifics? As I don't know which code you're talking about, I've no idea
what the actual problem is.
> In my case, I have to maintain a clean SUN development environment,
> so I am not allowed to install GNU tools.
I've installed them in parallel (which isn't really a problem) and
if you want to develop portable code and has to be compilable by GCC
as well.
> I suppose it's too late in the project to ask that you refrain
> from using GNU-specific code extensions, and GNU-only tools.
I don't know whether armaggedon is really that near and it's
certainly not a now and here option. Anyway, the number of necessary
GNU tools has been decreased: GNU make and autoconf/automake are
not necessary any longer.
> It kills the portability of the code, but since your primary user
> group is likely to be Linux-based, it probably isn't high on
> your wish list.
There's no Linux-dogma. It's just that mostly Linux users want to
use and develop Gtk-Gnutella. Maybe HP-UX, AIX, RiscOS users etc. are
too lazy or give up too soon? ;-)
> For instance, Solaris provides a native xgettext, and the configure
> program accepts that, but then uses GNU-specific arguments to the
> command line, which causes the make to fail.
Sure, there are many parts waiting for someone to clean them up,
ehance them, repair them. Unfortunately, this happens rather seldom.
OTOH, personally I've never gave a damn about I18N. I'd rather
revoke the babylonization of the human language. English is surely
not the perfect language but it's rather easy to learn and if everyone
were forced to use it, there would be less problems.
> I also found someone using:
> switch(var)
> case 'A...Z':
> case 'a...z':
Where? I couldn't find it. Maybe it has already been removed but
I didn't see any comment about it.
> This is totally illegal in every version of C except for GNU. So
> again, you are locked to the GNU tools, unless you know what to do
> to fix this. Of course, I had to insert the 62 missing case
> statements to fix this.
Two simple `if's should do the job.
> Luckily, the end result in the compiler
> output is probably identical. So it's really lazy coders causing
> these problems, not the compiler itself.
That's somewhat unfair. You cannot cross a bridge until you've
come to it. There's not really a (free) alternative for GCC when you're
using Linux.
> You might want to change
> your coding guidelines in the future, to try to inforce better
> portability to other platforms.
Well, the guide should be small and mention only the most important
and non-obvious points. You don't really want to attach the ISO
C99 standard. Gtk-Gnutella is developed with portability in mind but
it's very time-intensive to ensure it really is at any time. Every
platform and compiler have their own pitfalls so this can always
only be a best-efford practice and it absolutely depends on users
to report bugs, problems, compiler warnings(!) etc.
> For instance, the current code would never compile on Sun Sparc,
This is either a recent problem or has to be rejected. 0.92.1c
compiled flawless with SUN's Workshop Pro compiler 8.0 and was
useable - although not heavily tested.
> IBM's AIX, or HP's HPUX systems, using the commercial C compilers.
There were no reports, requests and maybe no requirement at all. Nobody
can fix problems he isn't aware of.
> Any site doing commercial development is likely to use the native
> commercial compilers, because they can get good paid support for
> the tools.
That might be true and I could list dozens of popular programs which
won't compile with anything but gcc or even worse: They compile but
contain non-obvious portability bugs and/or crash all the time etc.
Nevertheless, GNU tools are free, it would be far worse vice-versa
i.e., if you needed commercial tools to get things started.
> I was also amazed at the third-party support libs required.
This isn't mv, ping or ftp. Gtk-Gnutella is quite complex and
GUIs will always add a lot dependencies and "bloat". However,
all libraries you mention are required but almost any GTK program
and also used by many other stuff. I don't think there are many
up-to-date desktop system which miss these.
Let me rearrange the libs:
gtk+-2.2.3 needs these:
atk-1.2.4
glib-2.2.3
jpeg6b
libpng-1.2.5
pkgconfig-0.15.0
pango-1.2.5
tiff-v3.5.7
Gtk-Gnutella itself needs those:
gtk+-2.2.3
glib-2.2.3
libxml2-2.5.11
zlib-1.1.4
pkgconfig-0.15.0
Well, pkgconfig isn't really necessary but it's supposed to be cleaner
than gtk-config, glib-config, gnome-config etc. I don't think you want
to recommend to import those libs into the gtk-gnutella tree or to
re-implement them. They're also pretty portable AFAIK.
> And the people doing development
> are usually kids on a linux box, who could care less about
> portability.
Unless everybody uses a different platform you can always complain
about one having too much marketshare. IMO, it's war worse that
everyone and his little brother uses x86 hardware.
> Anyway, I wonder if it might be possible to downsize the
> number of libs you depend on, at some future time? While you
> may need some of these libs, I am sure you could eliminate
> two of the three image libs, and certainly pkgconfig, and
> perhaps zlib.
How and why? Gtk-Gnutella cannot be the (only) program which depends
on these (it doesn't depend directly on the image libs as mentioned
above). You cannot blame the Gtk-Gnutella developers for problems
with them and they could have choosen worse libs.
> If there is more that I can do for you, or more information
> that I can provide, please let me know, and I will do my best
> to provide it.
You should at least mention which code exactly causes problems with
your compiler and also report all compiler warnings as they might
indicate serious bugs.
--
Christian
pgp00000.pgp
Description: PGP signature
