(I've subscribed to this list now.)
Maurice Lombardi wrote:
Mariano Alvarez Fernandez wrote:
Frank Heckenbach escribió:
The rest of this mail is referring to the Pascal interface. Since I'm one of the GPC maintainers, I'm mostly interested in that.+
Because I don't know Pascal I will commit the changes, but I will wait for comments from pascal users (Maurice, can you check it?)
Relax. Franck knows better gpc than I do. He is one of the two chief maintainers of gpc, I am only an user.
But I don't know GRX so well yet ... ;-)
Now I have applied all his patches to check if there is nothing particular in djgpp with respect to X11 (adding also the install-font target into the top level makefile.dj2). Everything is correct as expected. I have only a couple of comments and suggestions.
- with respect to GRX_DEFAULT_FONT_PATH (diff1) The error was only in X11, djgpp case was working correctly, but used a different trick than that suggested by Franck, namely
#GRX_DEFAULT_FONT_PATH=c:/grxfonts is not quoted in makedefs.grx, but CCOPT += -DGRX_DEFAULT_FONT_PATH="$(GRX_DEFAULT_FONT_PATH)" is escape quoted in src/makefile.dj2, to avoid the " being eaten by the shell as Franck indicated. I see no reason to choose, but be consistent.
I don't mind either way, and I agree that it should be consistent.
the c:/grxfonts directory is not created if it does not exits: the attached diff10 does that.
Reading diff9, about differences in pascal between pointer
and arrays, this is exactly the reason I had suggested changes in polygon functions in the bgi2grx (graph) interface (which were already applied).
Yes, I saw them and found that some programs of mine that use them which failed with older GRX versions work now.
But the same error remains in the grx interface, where all polygon functions will not work as they are written.
Indeed, I hadn't seen them.
I have made the changes in grx.pas, and also written a new pascal/polygon.pas demo program, which is the translation to pascal of the test/polygon.c demo to check it. It includes the same way of giving the graphics parameters on the command line by typing e.g. polygon 1024 768 64k
Works for me.
but without the uggly trick of creating a GRXmain which uses the test function as a callback function. Why do simple when you can do complex ? Or may be there is some c reason I do not understand.
I don't know which ugly trick you're referring to, but ISTK that the GRXMain stuff is needed on mingw (only?). Therefore I inserted the following in my GRX programs:
{$ifdef __MINGW32__} {$gpc-main="GRXMain"} {$endif}
Note that I don't use mingw myself; Nicola Girardi (who you probably also known from the GPC list) compiled the code for me, and it seems to work like this.
Or you pass --gpc-main=GRXMain on the command line, as the makefile.w32 does in GRX.
Even better it would be if the compiler directive as above could be in the GRX and Graph units rather than having to be given for each GRX program, but GPC doesn't support that yet -- it's on our todo list. Well, maybe it's not hard to do, actually; I'll look into it next week ...
This is included in diff11 (to be applied after Franck's diffs), together with changes needed to all makefiles in the pascal directory.
Just compiled GRX again with your diffs and had no problems.
Then, I tried to build GRX on Sparc/Solaris. Besides having to set -lsocket as noted, there were a few more problems:
- Building shared libs failed. This might be a local installation problem since I've had some problems with shared libs there before, but it might also be a matter of compiler/linker options (ISTR that the options required very from system to system, that's why libtool was invented, but I don't know much about libtool myself). For now, I just disabled shared libs by editing the makefiles, but I think this should be possible via makedefs settings (or is it possible, how?).
- test/bgi/bccbgi.c fails because it tries to include <pc.h> (on every platform except Linux and mingw, while it only exists on Dos, AFAIK). - same bug in test/bgi/fontplay.c - same bug in test/bgi/tellipse.c - same bug in test/bgi/tfill.c - same bug in test/bgi/tpoly.c - same bug in test/bgi/ttext.c (diff12)
- The install target(s) should created the directories (e.g. include, lib, info) before trying to write into them. This is particularly necessary when installing in a temp dir in order to build a binary distribution. (I didn't make a patch for that yet.)
- /etc/infodir seems to be hard-coded in the makefile. That's bad! (Not everyone is root. ;-) I strongly suggest this directory to be configurable, and to make the whole install-info stuff optional (or get rid of it at all -- something like @dircategory and @direntry in the texi file might be better, since it allows the system tools which (re)build the info directory to recognize it).
After working around these problems, however, I was able to build it and run the test programs and some of my Pascal programs successfully.
Another idea: How about a configure script for GRX? It could just make a copy or link of the respective makefile.foo to Makefile and set some options in makedefs from the command line. This way, it would be purely optional (i.e., the current way of building GRX would still work, but those who prefer ./configure && make (like me) could do that then).
If you don't reject the idea, I could probably write such a little script (only for X11, svgalib and perhaps DJGPP -- but I guess users on other platforms wouldn't expect to run configure, anyway (or mingw, maybe?).
Frank