Michael Sweet wrote:
> gga wrote:
>> ...
>> Fluid should be killed as a C++ project and rewritten in a scripting
>> language. Its code base is unmaintainable as it is. I started porting
>
> That will make it unusable on all non-current systems. No thanks!
>
Huh? Not sure what you mean. Most of the popular scripting languages
run on all sort of platforms, from most OSes to even embedded systems
(albeit I doubt anyone uses fluid there). Some have java ports (JRuby,
JPython) and clr/mono ports (IronPython, IronRuby, etc), making them
even *more* portable (today or in the near future).
Why do you think C++ is more portable in this day and age?
>> autoconf/configure should be killed
>
> Why?
>
Usually slower compilation due to less efficient Makefiles.
Adding complex dependencies is also a nightmare with autoconf.
(albeit these two for a small project like fltk are not an issue).
Out of source builds are often a pain to set up.
Proper testing forces a 3 step process (autoconf, configure and make).
Autoconf scripts are also VERY easy to break and require lots of
utilities to be installed (an almost full unix toolset, depending on
what you do). They are not truly multiplatform (no native ms windows,
for example). This forces manually maintaining all the .vcproj files
for windows, which prevents easily adding/removing files to the project.
It also has no support for automatic testing, packaging or distribution,
all of which make it easier to add bugs to fltk without noticing.
cmake, for example, is currently a better replacement for autoconf, in
most of these aspects. It should also run on pretty much every system
autoconf runs (or easily allow cross compilation for them).
This allows you to also support nmake and .vcproj/.sln files or KDevelop
files for those that prefer using GUIs for compilations all from a
single location.
CMake also has one of the best systems for detecting outside
dependencies (and one of the largest libraries for it), which can be
useful for fltk to detect additional libraries (xft, pango, cairo, etc).
Albeit it requires an installation of the cmake utility (as no OS ships
with it installed), it is only one utility instead of hundreds.
Also, it supports UNC paths properly unlike autoconf, which is important
if trying to compile on a mixed network.
Only thing I truly dislike about cmake is that its distribution
packaging is not as good as epm or installjammer and the overall syntax
could also be a tad simpler (but it's already an improvement over
alternatives like autoconf, scons, etc).
Another plus for cmake is that FLTK1.1 already has a CMakeLists.txt
(which seems like it is up to date, albeit it currently unfortunately
creates silly files all over the place when run, making it almost as bad
as autoconf).
The biggest drawback of cmake compared to autoconf for FLTK afaik is
that it does not yet allow building a shared and static library from the
same .obj files on windows (it forces you to create two out of source
builds, which is inefficient).
>> FLTK's footprint needs to be made smaller by proper use of Makefiles.
>
> How? If you remove autoconf/configure, then you lose the ability
> to support a diverse range of systems.
>
Sorry, this should not read proper use of Makefiles but proper use of
compiler options. Currently fltk is incorrectly exposing all of its
symbols instead of stripping them. This makes the fltk .so library be
several megs when its footprint could probably be reduced to only a
couple of Kb (or forces you to link it statically and be locked to a
specific fltk version).
Using __attribute__("hidden/visible") calls for gcc and DLLEXPORT stuff
on windows and having the makefile strip symbols should bring fltk's
footprint to something *much* more competitive to any other toolkit.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
