gga wrote: > 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?
Because you can get a C++ compiler on any OS, compile your software, and then reuse the binaries for that OS. Since C++ is a requirement for FLTK anyways, that works well. Requiring (Python|Perl|Ruby|Java|whatever) will hinder portability because a) compiling them can be tricky or b) there may not be a source for your OS at all (think Java). Finally, if we can't write FLUID using FLTK and C++, why would anyone want to use FLTK in the first place? >>> autoconf/configure should be killed >> Why? >> > > Usually slower compilation due to less efficient Makefiles. Have you looked at our makefiles? There are few (if any) inefficiencies. We *don't* use automake and libtool specifically for the inefficiencies and incompatibilities they introduce, perhaps you are thinking of those? > Adding complex dependencies is also a nightmare with autoconf. Huh? > (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). Oooh, sounds hard. > 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). I don't get that. You just need a POSIX shell and a new enough m4 - GNU m4 is trivial to install on older systems. Once the configure script is created, you just need a POSIX shell. The FLTK configure script does use the uname utility, but that has existed *forever* on UNIX. If you decide to use Cygwin/MingW on Windows instead of VC++, they also include a version of the same utility. > 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. True, but Windows also has very different build requirements thanks to its (twisted?) DLL mechanism. Also, there is no "native ms windows" project file format - Microsoft CHANGES the format with every release of VC++. Even the available make/autoconf replacements don't support every version, and that would introduce yet another dependency for little gain. > It also has no support for automatic testing, packaging or distribution, > all of which make it easier to add bugs to fltk without noticing. I guess you've never setup a build farm, then? Except for Windows (which I haven't bothered to setup, at least yet), I have an automated build system setup for FLTK (and the rest of the software I maintain) on AIX, HP-UX, IRIX, Linux (i386 and x86_64), Mac OS X (ppc + intel) and Solaris (i386, x86_64, and sparc). I see when something is broken (in 1.1.x) and can fix it by the next day. > 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). ... and you have to build and install it on every system, no thanks. Also, what happens when your platform of choice isn't supported by cmake? FLTK works with the standard OS tools (make, shell, compilers for UNIX, VC++ for Windows), something that (IMHO) has helped it to stick around so long. Bundling the image library dependencies in 1.1.x made it even more accessible. Adding an external dependency to build the library will just make it less accessible. > ... >>> 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). > ... Few platforms we support allow you to limit the visibility of symbols - basically just newer versions of Linux and Windows. Also, you're not going to reduce the size that much - we have no private APIs that are externally-accessible that don't need to be. Any symbols you see in the .so are either public APIs/methods that need to be exported or functions we are using within FLTK that the run-time linker needs to resolve for us. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Publishing Software http://www.easysw.com _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
