In article <3DC56FF9.C8C8BCA5@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> rame.h is the first of the POV-Ray include files but the standard include
> files are sometimes before, sometimes after them.

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.

So now you can be sure the "wrong" BLOB is always defined and included and
used prior to the "correct" BLOB being defined.  The next step is to add
what Warp suggested after the "wrong" BLOB has been defined.

Now compile.  If it still fails, continue adding the Windows specific header
files or whatever other files cause problem to config.h as outlined above.
This solution will work because all proper header files are protected from
double-inclusion.

Of course, the better solution would be to eliminate the inclusion of
windows.h, but if you are not sure how to do that without breaking anything
or where it is coming from, then the above will work as expected, only
compile a bit slower at worst.

    Thorsten


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.)

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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.

> and this would lead to a lot of modifications.  In general i
> think it would be best to have no more modifications than necessary.

I will check further propositions from this thread.

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.

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. It is
used in the same shell as DJGPP but it truncates command line at some
possition. I had to move this command from general process to each object
processing (add each object 'manually' after compilation), ie:
  bbox.o:
    g++ $(CFLAGS) -c -o bbox.o bbox.cpp
    ar rcs libsrc.a bbox.o
The same problem is not only for 'ar'. It is connected with command line in
MinGW with all tools, for example when more longer include paths is added with
-I.

ABX

Post a reply to this message

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