Maurice Lombardi wrote:

Frank Heckenbach wrote:

...

as I said recently, I wrote a small configure script now. The script is completely optional, i.e. those who don't want to use it can configure GRX manually just like before, but those like me who don't want to edit config files by hand should not need to do this anymore.

It will just create a link from the appropriate makefile.foo to Makefile (so you can invoke make without `-f makefile.foo' afterwards)

but DJGPP has no symlinks ln -s (except for executables). Replaced usually by copy (needs a test)

OK, I've done this in the following patch (and also replaced the `[ -L ... ]' which also failed on Solaris for another reason by a series of file compares which should work on DJGPP with cmp, and fixed an "8+3" issue in configure).

While running the pascal tests I have seen that if we stick to the old policy it is necessary to introduce -lpng in makefiles to enable the imgviewer to compile (diff24). Of course these makefiles can be greatly simplified if one supposes the configure way.

Not only then. Also if the `{$L}'s are set manually, the `-l's are not necessary for Pascal. I was going to suggest this, anyway because I noticed a problem on Solaris, and have already prepared a patch.

The other thing is, I'd intentionally not put imgview in an ifdef in the makefile, because the program checks GrPngSupport and GrJpegSupport itself, so it should work properly if only one of them is enabled (only with the corresponding file format then, of course), and even is none is installed, it should print a proper message. So I'd prefer to build it in any case.

Some other things I noticed on Solaris:

- The Solaris shell doesn't understand `[ -e ... ]' (known issue with other packages). `-r' can be used instead which seems to be understood by all shells (affects configure and src/makefile.{lnx,x11}).

- There were problems with redeclaration of `ushort'. Since that's a typedef (not a #define) it's not easy to check if it's defined in the system header (without autoconf, but I guess you don't want to use autoconf ;-). Since it's used only locally in some src/bgi files, I think it's easiest to just rename it, which I'm doing.

- bgi/text1.c:70: warning: `temp1' might be used uninitialized in this function Unlike most of these warnings given by GCC, this one is justified. ;-) temp1 can indeed be used uninitialized (though in a rather unlikely case it seems). You might want to take a look at my fix, but I think it should be ok now.

- For `-lsocket' (needed on Solaris as noted), I'm adding a placeholder in the Pascal units. Also, configure can now set it (and LINUX_CONSOLE as well) when necessary.

- As said above, I removed the `-l's from the Pascal makefiles which are not necessary when the `{$L}'s in the units have been set.

With these changes I could build GRX on Solaris with just `--enable-lsocket --disable-shared' in addition to my other configure options.

All of this is in diff24.new. As the file name says, I suggest to apply this instead of Maurice's diff24, for the reasons given above.

When running imgviewer with djgpp on the images contained in the test directory it gives very bad results for two reasons:

• the 320x240 screen: this was for old VGA-only setups: everybody has a VESA/SVGA now.
• BPP should be 24 as in other tests of jpeg/png

With the corrections (diff25) all seems perfect.

Thanks. (Though it crashes the console in DosEmu on my system, but it works in xdos.)

Frank

Maurice Lombardi wrote:

...

All of this is in diff24.new. As the file name says, I suggest to apply this instead of Maurice's diff24, for the reasons given above.

I agree. This is better.

I have made corresponding changes for pascal/bgi (diff25) and checked them.

Did you confuse the file names? What you sent is the same diff25 you sent last time (resolution in imgviever).

Anyway, even for manual editing (which should always be documented for djgpp and mingw minimal configurations), it must be added after "edit makedefs.grx":

If you plan to use pascal (gpc), and not use configure, edit the files pascal/grx.pas and pascal/bgi/graph.pas to uncomment the {$L ...} instructions (near the beginning) to load the auxiliary libraries (png jpeg tiff z) you have.

For the configure script I have found a problem with djgpp (and presumably also mingw): if you have all libraries, a prefix, a fontpath and a libsubdir, you overcome the 126 chars dos limit for length of command line. [...] The solution is to enable shortcuts e.g., -en- for --enable- and -di- for --disable-

OK.

Furthermore I see no reason not to keep separate libsubdirs with default names like previously. (this will save an option):

Oh, that's where the libraries are built, I see. I had assumed it's where to install the libraries, and in this case, it would have seemed strange to me to use a prefix (like /usr/local/lib/unix/libgrx.a). Now, I agree to keep the prefix (in fact, I'll remove the option to change the libsubdir from configure since it's more like an internal setting which the user shouldn't normally need to change).

All in diff27 (assuming your patch is diff26), including the readme addition.

compiling both djgpp and mingw in the same tree is probably not so an unlikely issue

BTW (I don't care much myself, just curious): How about building, say Linux console and X11? Shouldn't they use different libsubdirs also?

(and libraries are currently not deleted with clean).

BTW, some other files (fnt2c, bin2c, xmodetest in bin) are also not deleted with clean. Is this intentional, or should I add them to the clean rules?

Frank

Maurice Lombardi wrote:

...

BTW, some other files (fnt2c, bin2c, xmodetest in bin) are also not deleted with clean. Is this intentional, or should I add them to the clean rules?

Probably not intentional. Just do it.

When I was about to do it, I saw that there are (undocumented) `cleanall' rules which do it. So it seems to be intentional that plain `clean' doesn't ...

Frank

Mariano Alvarez Fernandez wrote:

Frank, you know, I dont't like really to add a configure script, because I think it complicates the install instructions and add another thing to maintain, without real advantages to the distribution. Also, stock DJGPP and Mingw users don't install bash, sed and fileutils.

As I said, it's completely optional. A DJGPP user who doesn't install additional tools doesn't want to run it and can just build GRX like before.

About the instructions: If you think they would get too complicated, we can just not document configure there. Those who know about configure scripts will find it, anyway (and I can add some words to the `configure --help' output to make clear that it's optional etc.). I haven't changed anything in the install instructions yet, but that was because I forgot it. Now, if you don't want it, we can just leave them alone (otherwise, I could still write some words about configure for the install instructions).

About "real advantages", we'll probably disagree. I've build GRX from scratch for about 5-10 times now (you probably a lot more), and I think it's a huge advantage to just call configure instead of editing some files each time (even though the latter can be automatized, of course, but it's still much more clumsy).

Probably a new user, doesn't edit makedefs.grx at all and try make -f directly, this is ok. The same user probably will be bewildered with the configure questions.

Questions? There are no questions. Just running configure will set (leave) the defaults and create a Makefile. The configure options only come into play when in the other case they'd have to edit files by hand.

About new users: On DJGPP probably yes, but as I said, most DJGPP users will probably ignore configure and do jsut like before.

On Linux (I doubt whether there are "new users" on other Unix flavours ;-), they'll probably have built some other packages already before trying such a rather complicated build as GRX, so they are familiar with ./configure && make. (And otherwise, again, they can jsut ignore configure.)

So, if you like, we can put a big warning on it "PLEASE IGNORE THIS FILE IF YOU DON'T KNOW WHAT A CONFIGURE SCRIPT IS" ;-), and you can just consider the script a useless file to carry around which everybody ignores. (Well, not really everybody, you know ... ;-)

Frank