Thorsten Froehlich wrote:
> 
> Yes, so what is the problem?  No modifications needed!  If you cannot just
> keep the windows header files out (what are they doing in a Unix project in
> the first place???), all you want it to adjust config.h properly!
> 
> So near the top of config.h add the offending file.  You suggested it seems
> to be windows.h in your case.

All right, this could work (including the file at the beginning and
defining the preprocessor replacement afterwards).

> 
> BTW, did you notice that the Windows version compiles without this problem
> and without modifications...?  You may want to check how it solves this
> problem!  (I did not bother.)

I did not find anything in the WinPOV source but the standard header files
of the windows compilers could be different.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 02 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

ABX wrote:
> 
> On Sun, 03 Nov 2002 16:27:07 +0100, Christoph Hormann <chr### [at] gmxde>
> wrote:
> > I'm not sure this is a good idea.  The 'BLOB' type occurs at quite a lot
> > of places
> 
> Not so much. Only 4 files IIRC.

But a whole bunch of places in those files.  Just think about the awful
lot of work to regenerate those modifications in a future (3.50d) version
in case those files have been modified.

If it really works (i have not tested yet) the '#define BLOB POV_BLOB'
seems a better idea.

> 
> BTW: I have not checked MinGW with Cygwin. I'm using it separated. I can't
> find any INT32 conflict there so perhaps it is becouse of CygWin ? Comparing
> compilation of POV3.5 with DJGPP and MinGW on the same machine DJGPP
> compilation process is twice faster (I use exactly the same settings becouse I
> use one shared makefile for them). It is probably becouse of extended headers
> with all those windows constants from w32api. I have not tested speed of
> exacutables but I have seen your results in general.

Faster compilation does not mean anything.  In fact i noticed it compiles
fairly slow too (more than 20 minutes for all files IIRC) and since DJGPP
produces a DOS executable it is really not the question if it is faster or
not in execution either.

> I have found one problem with pure MinGW. There is some problem with length of
> commandline. For example I have no problem with creating archive/library with
>   ar rcs libsrc $(LIST_OF_SRC_MEMBERS)
> when DJGPP is used. But it fails when pure (no cygwin) MinGW is used.
> [...]

The DJGPP ar is probably a DOS program while the MinGW version is a
windows executable.  This might make a difference.  No problems with
Cygwin (and bash) in that concern.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 02 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Mon, 04 Nov 2002 11:42:47 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> If it really works (i have not tested yet) the '#define BLOB POV_BLOB'
> seems a better idea.

I have tested and it seems works as weel as '#define rad2 rad_2'.

> In fact i noticed it compiles
> fairly slow too (more than 20 minutes for all files IIRC)

You can imagine how long it compiles on Pentium 75 :-)

ABX

Post a reply to this message

On Mon, 04 Nov 2002 11:32:36 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> > BTW, did you notice that the Windows version compiles without this problem
> > and without modifications...?  You may want to check how it solves this
> > problem!  (I did not bother.)
>
> I did not find anything in the WinPOV source but the standard header files
> of the windows compilers could be different.

w32api boundled with MinGW is something like recreation of Windows API for
opensource projects

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mingw/w32api/README.w32api?rev=HEAD&content-type=text/vnd.viewcvs-markup

ABX

Post a reply to this message

On Mon, 04 Nov 2002 12:13:20 +0100, ABX <abx### [at] abxartpl> wrote:
> I have tested and it seems works as weel as '#define rad2 rad_2'.

BTW: for those who don't like unnecessary warnings :-)
it is better to #under BLOB and #undef rad2 first.

ABX

Post a reply to this message

On Sat, 02 Nov 2002 16:25:45 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> I don't know if the
> plain MinGW works as well but there could be tools missing required by the
> configure script etc.

Oh, I forgot one thing more. There are missed asinh, acosh and atanh functions
in plain MinGW. I had to add somewhere:

#if defined( __MINGW32__ ) && defined( MINGW_MISSED_FEATURES_PATCH )
  inline DBL asinh(DBL val){return (DBL)log(val+sqrt(val*val+1));}
  inline DBL acosh(DBL val){return (DBL)log(val+sqrt(val-1.0)*sqrt(val+1.0));}
  inline DBL atanh(DBL val){return (DBL) 1/2*log(val+1)-1/2*log(1-val);}
#endif

ABX

Post a reply to this message

ABX wrote:
> 
> Oh, I forgot one thing more. There are missed asinh, acosh and atanh functions
> in plain MinGW. I had to add somewhere:
> 
> #if defined( __MINGW32__ ) && defined( MINGW_MISSED_FEATURES_PATCH )
>   inline DBL asinh(DBL val){return (DBL)log(val+sqrt(val*val+1));}
>   inline DBL acosh(DBL val){return (DBL)log(val+sqrt(val-1.0)*sqrt(val+1.0));}
>   inline DBL atanh(DBL val){return (DBL) 1/2*log(val+1)-1/2*log(1-val);}
> #endif

No, just use:

#define NEED_INVHYP 1

:-)

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 02 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Mon, 04 Nov 2002 19:19:44 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> :-)

:-)

ABX

Post a reply to this message