Hi.
I have uploaded a pre-release of GRX 2.4.4. Download it from:
http://grx.gnu.de/download/grx244p1.zip
MD5SUM for the package:
ee807ba1edf3c20fdff8c62fe249ca62 *grx244p1.zip
Only the zip archive is provided, but note, the zip archive expand to grx244, not to the contrib directory.
Changes from 2.4.3:
- added the changes to the pascal interface. - new functions to load/save jpeg image files. - the info install has now his own targets: install-info, uninstall-info - added "-lm" to make grx programs in the linux console makefiles, it is not ever necesary, but it doesn't hurt.
Testing and comments will be welcome.
Mariano Alvarez Fernandez schrieb:
I have uploaded a pre-release of GRX 2.4.4. Download it from:
Thanks a lot.
http://grx.gnu.de/download/grx244p1.zip
Testing and comments will be welcome.
src/makefile.dj2: if not exist $(DOS_DJGPP_V2) del $(SYSTEM_TAG_PREFIX).* ^^^ src/makefile.w32: if not exist $(WIN32_i386) del $(SYSTEM_TAG_PREFIX).* ^^^ IMHO the 'not' should be removed :)
What do you think about adding the mechanism of creating the grx*.ver grx*.mft grx*.dsm files for DJGPP to the 'make install*' stream ?
generic question: did anyone succeed building TIFF/JPEG/PNG support for MINGW32? If yes, could a how_to be supplied?
Waldemar Schultz escribió:
src/makefile.dj2: if not exist $(DOS_DJGPP_V2) del $(SYSTEM_TAG_PREFIX).* ^^^ src/makefile.w32: if not exist $(WIN32_i386) del $(SYSTEM_TAG_PREFIX).* ^^^ IMHO the 'not' should be removed :)
No, that is correct, if the tag file for the makefile you are using don't exist, all possible tag files are removed and a clean is executed.
What do you think about adding the mechanism of creating the grx*.ver grx*.mft grx*.dsm files for DJGPP to the 'make install*' stream ?
.ver and .mft files will be added with the real 2.4.4 release (and the tar.gz package). I don't know how to make a .dsm file, so contibutions are welcome.
generic question: did anyone succeed building TIFF/JPEG/PNG support for MINGW32? If yes, could a how_to be supplied?
Yes, it works, the easy way is to get the binaries from http://mingwrep.sourceforge.net/
Mariano Alvarez Fernandez schrieb:
if not exist $(WIN32_i386) del $(SYSTEM_TAG_PREFIX).* ^^^ IMHO the 'not' should be removed :)
No, that is correct, if the tag file for the makefile you are using don't exist, all possible tag files are removed and a clean is executed.
o.k. I see, was just confused by the message like 'bad command or file not found'
.ver and .mft files will be added with the real 2.4.4 release (and the tar.gz package).
good, thanks.
I don't know how to make a .dsm file, so contibutions are welcome.
ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/dsm-spec.txt
# Required directive 'dsm-author' # Required directive 'dsm-file-version' # Required directive 'dsm-version' # Required directive 'dsm-name' # Required directive 'type' # Required directive 'name' # Required directive 'version' # Required directive 'short-description' # Required directive 'zip'
something like this should do (could be a script output) grx244s.dsm: ___ # # DSM for grx 2.4.4 sources # Copyright .................... #
dsm-author: Mariano Alvarez Fernandez dsm-file-version: 2.0 dsm-version: 0.4.4 dsm-name: grx244s dsm-type: sources name: grx version: 2.4.4 short-description: DJGPP 2-D graphics package wit BGI emulation zip: grx244s.zip
dsm-author-email: malfer@teleline.es manifest: grx244s author: M........................ author-email: m.......................... web-site: http://www............. ___
Yes, it works, the easy way is to get the binaries from http://mingwrep.sourceforge.net/
O.K. I'll give it a try.
some remarks on MinGW32 version of BCCBGI: putpixel: has bad timing get/put image: bad XOR mode textmode: looses scope if you click palette play: doesn't work (esp. gray) polygons: don't work
some remarks on MINGW32 version of DEMOGRX: mousetest: no cursor modes, wrong colors(XOR)
Thanks a lot.
Mariano Alvarez Fernandez wrote:
I have uploaded a pre-release of GRX 2.4.4. Download it from:
Works well for me, except that my "diff12" (some wrong inclusions on non-PC systems in test programs) hasn't been applied yet.
- 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.)
I'm not sure if we must do it.
If you don't, then install will copy, say, grx.h to a file called include instead of a file grx.h in a (non-existing) directory include.
Ok, my doubts was about the convenience to expand the /usr/local tree without user permission.
I think we can safely do it. Most other packages I've seen do the same.
- /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
Ok, but people who use the install target are suposed to be root anyway.
IMHO a very unfortunate attitude, also known as "Linux arrogance". There are actually Unix systems where not every user is or can become root (like, e.g., me on our university's machines), and they might want to install things in their home directory (which works with GRX except for the hard-coded /etc in one place).
Ops! I wanted to mean, that the automatic install target is normally for the superuser, normal users can move by hand the four files to the location they want (and the readme file says what files to move).
And I don't agree here. ;-) If they specify a suitable prefix directory (where they have write permission), they should be able to install it automatically IMHO. Apart from that, /etc/info-dir is not even correct on every Linux system -- on mine (SuSE) it's /usr/info/dir.
And the console linux target don't work at all if you are not supersuser, because it uses svgalib.
I'm not really talking about this one, anyway. ;-)
(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).
Sorry, I don't know well TexInfo to understand this.
Something like the following:
@dircategory Libraries @direntry
- GRX: (grx). The GRX Graphics Library.
@end direntry
Ok, thanks, where we must leave the info file?,
The location of the info file is ok, I think ($(INSTALLDIR)/info).
what utility must the user run after?
As far as I understand it (and see it in other packages), simply:
install-info --info-dir=$(INSTALLDIR)/info $(INSTALLDIR)/info/grx.info
Another thing:
I've now made GPC to allow `gpc-main' in units, so this can be inserted (conditionally for mingw) into grx.pas and graph.pas. Of course, it will work only with the next GPC version (probably released today), but earlier versions will simply ignore it (no warning), so I don't think it needs to be surrounded with a version check. The (additional) passing of `gpc-main' from the GRX/mingw Makefile will also not hurt, so it can be left there for a while (until the new GPC version has spread). So, in the future, no GRX/GPC user should have to worry about `gpc-main' in their programs.
That's in diff13. It also contains some minor cleanups in the Pascal files.
Frank
Frank Heckenbach escribió:
I have uploaded a pre-release of GRX 2.4.4. Download it from:Works well for me, except that my "diff12" (some wrong inclusions on non-PC systems in test programs) hasn't been applied yet.
I have a problem here:
-#if defined(__linux__) -# include "bcclnx.h" +#if defined(__DJGPP__) +# include <dos.h> +# include <pc.h> #elif defined(__WIN32__) # include "bccw32.h" #else -# include <dos.h> -# include <pc.h> +# include "bcclnx.h" #endif
This break the Wattcom and TurboC targets, really they are unmaintained now, but I will prefer don't break it, if we can. So, what about other macros?, can we check for __unix__ or something similar?
Ok, my doubts was about the convenience to expand the /usr/local tree without user permission.
I think we can safely do it. Most other packages I've seen do the same.
Ok, I put it in my to do list.
Something like the following:
@dircategory Libraries @direntry
- GRX: (grx). The GRX Graphics Library.
@end direntry
Ok, thanks, where we must leave the info file?,
The location of the info file is ok, I think ($(INSTALLDIR)/info).
what utility must the user run after?
As far as I understand it (and see it in other packages), simply:
install-info --info-dir=$(INSTALLDIR)/info $(INSTALLDIR)/info/grx.info
Ok, thanks.
Another thing:
I've now made GPC to allow `gpc-main' in units, so this can be inserted (conditionally for mingw) into grx.pas and graph.pas. Of course, it will work only with the next GPC version (probably released today), but earlier versions will simply ignore it (no warning), so I don't think it needs to be surrounded with a version check. The (additional) passing of `gpc-main' from the GRX/mingw Makefile will also not hurt, so it can be left there for a while (until the new GPC version has spread). So, in the future, no GRX/GPC user should have to worry about `gpc-main' in their programs.
That's in diff13. It also contains some minor cleanups in the Pascal files.
Ok, thanks.
M.Alvarez
Mariano Alvarez Fernandez wrote:
I have a problem here:
-#if defined(__linux__) -# include "bcclnx.h" +#if defined(__DJGPP__) +# include <dos.h> +# include <pc.h> #elif defined(__WIN32__) # include "bccw32.h" #else -# include <dos.h> -# include <pc.h> +# include "bcclnx.h" #endif
This break the Wattcom and TurboC targets, really they are unmaintained now, but I will prefer don't break it, if we can. So, what about other macros?, can we check for __unix__ or something similar?
Perhaps replace __DJGPP__ by MSDOS or __MSDOS__. I don't know these compilers, so I don't know if they define these symbols, but if they do, this would seem the cleanest solution, anyway (<dos.h> and <pc.h> are Dos-only, so if it gets ported, say, to the Mac sometime, they shouldn't be used, either; therefore, I'd prefer to check for Dos explicitly if possible).
Frank
Frank Heckenbach wrote:
Perhaps replace __DJGPP__ by MSDOS or __MSDOS__. I don't know these compilers, so I don't know if they define these symbols
DJGPP defines both, and also __MSDOS
Maurice
Maurice Lombardi wrote:
Frank Heckenbach wrote:
Perhaps replace __DJGPP__ by MSDOS or __MSDOS__. I don't know these compilers, so I don't know if they define these symbols
DJGPP defines both, and also __MSDOS
And also unix and __unix__ (so we can't use that).
Do the other Dos compilers also define MSDOS or __MSDOS__?
Frank
Frank Heckenbach escribió:
Maurice Lombardi wrote:
Frank Heckenbach wrote:
Perhaps replace __DJGPP__ by MSDOS or __MSDOS__. I don't know these compilers, so I don't know if they define these symbols
DJGPP defines both, and also __MSDOS
And also unix and __unix__ (so we can't use that).
Do the other Dos compilers also define MSDOS or __MSDOS__?
My old BorlandC defines it (__MSDOS__), I don't know about Wattcom, but I think is safe to use __MSDOS__. So I will use it in your patch.
Mariano Alvarez Fernandez wrote:
Do the other Dos compilers also define MSDOS or __MSDOS__?
My old BorlandC defines it (__MSDOS__), I don't know about Wattcom, but I think is safe to use __MSDOS__. So I will use it in your patch.
OK, thanks.
Frank
-
Frank Heckenbach -
Mariano Alvarez Fernandez -
Maurice Lombardi -
Waldemar Schultz