Re: [fltk.development] consistent usage of WIN32 vs. _WIN32

2010-01-23 Thread Albrecht Schlosser
Albrecht Schlosser wrote:

 My main point is that we are consistently using WIN32 or _WIN32
 everywhere. If we decide to use _WIN32 everywhere, then we must
 also change the define in fltk-config and Makefiles (or makeinclude)
 or elsewhere. But please don't *mix* both, otherwise we'll maybe get
 into trouble.

Okay then, since nobody replied, I decided to change the existing
_WIN32 usages to WIN32 to make it consistent in all our code. The
only remaining usage is in test/sudoku.rc, but I don't think that
this is relevant here, and maybe it's even better so.

FYI: I found this in CHANGES:

CHANGES SINCE FLTK 1.0.10
[...]
- Replaced remaining _WIN32 symbols with WIN32.

Thus we can see that it was intentionally done in FLTK 1.0.10,
and it worked for a very long time now.

We could still change *everything* to use _WIN32, because I
agree with Ian that this might be the most portable way,
because many Windows compilers/toolkits seem to define this,
but I won't start this unless there is a good reason to do
it.

Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev


Re: [fltk.development] consistent usage of WIN32 vs. _WIN32

2010-01-23 Thread imacarthur

On 23 Jan 2010, at 14:02, Albrecht Schlosser wrote:

 Albrecht Schlosser wrote:

 My main point is that we are consistently using WIN32 or _WIN32
 everywhere. If we decide to use _WIN32 everywhere, then we must
 also change the define in fltk-config and Makefiles (or makeinclude)
 or elsewhere. But please don't *mix* both, otherwise we'll maybe get
 into trouble.

 Okay then, since nobody replied,

Sorry Albrecht - I thought I had replied, but now I think I only  
*meant* to reply but never got round to it...
I think it is correct to change everything to use WIN32.
I think I did go in and change back (to WIN32) the few I had changed  
(to _WIN32) that started off this discussion, though.

(Also, I think most of the other instances were probably introduced  
relatively recently, by people used to the MSVC tools where the  
_WIN32 pattern is standard.)


 I decided to change the existing
 _WIN32 usages to WIN32 to make it consistent in all our code. The
 only remaining usage is in test/sudoku.rc, but I don't think that
 this is relevant here, and maybe it's even better so.

Yes - I do not know what environment variables may be in scope for  
the resource compilers, so it may be best to leave this one alone!



___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev


Re: [fltk.development] consistent usage of WIN32 vs. _WIN32

2010-01-23 Thread Greg Ercolano
Albrecht Schlosser wrote:
 Okay then, since nobody replied, I decided to change the existing
 _WIN32 usages to WIN32 to make it consistent in all our code. The
 only remaining usage is in test/sudoku.rc, but I don't think that
 this is relevant here, and maybe it's even better so.

Sounds good.

I think its precise meaning should be defined in the CMP,
and a short description of how it should be used.

In fact, all 'global practices' should probably be documented
there, either under Macro Use or some miscellaneous category.

As it is, WIN32 is not mentioned:
http://fltk.org/cmp.php
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev


[fltk.development] consistent usage of WIN32 vs. _WIN32

2010-01-07 Thread Albrecht Schlosser
[ starting a new thread intentionally ]

MacArthur, Ian (SELEX GALILEO, UK) wrote in thread
[fltk.development] Fltk-1.3 and Fl_Preferences:

[ Albrecht Schlosser wrote: ]
  I took a look at your patch and stumbled over this:
 
  -#ifdef WIN32
  +#ifdef _WIN32
 
  Why did you change this? My understanding is that FLTK defines
  WIN32 (without underscore) for all FLTK Windows builds, and
  this is used everywhere in the code. I assume that this has been
  done to be independent of maybe different macros of different
  compilers.
 
  Yes - I probably should not have changed that. It should not matter
  but...

It does matter if _WIN32 is not defined, however. And maybe there
are other compilers that don't define it (but see below).

  Anyway, I changed it because:
 
  - we define WIN32 in our builds

That I don't understand.

  - the gcc win32 tools define WIN32 anyway, and also _WIN32 and
quite a few other variants... On this mingw setup, all of these
are set by default for every build:
WIN32 _WIN32 __WIN32 __WIN32__

okay, I can see this with cygwin/gcc -mno-cygwin, too.

  - the MS tools do not define WIN32, but do define _WIN32 and a few
others, I forget what.

That's why _we_ define WIN32, IMHO.

And what about Borland, Watcom, and ... (who knows)?

Cygwin (in cygwin mode) defines none of them, and we rely on
WIN32 being defined.

  So, for maximum portability, we should not be depending on WIN32 being
  defined, but it seems that we can depend on _WIN32 being defined.
  Possibly.

Again: my assumption is that we (FLTK) define WIN32 to have to test
only one macro. But maybe that's for other historical reasons.
Otherwise we would end up with something like this (found in
png/pngconf.h:

#if defined(PNG_DLL) || defined(_DLL) || defined(__DLL__ ) || \
 (( defined(_Windows) || defined(_WINDOWS) || \
defined(WIN32) || defined(_WIN32) || defined(__WIN32__) ))

  There have been a few posts from MS VS users who have got themselves
  into trouble recompiling files from the tarball and NOT setting WIN32
  in their builds and wondering why things go bad...

Isn't that their problem ;-) ? Using FLTK code in a non-FLTK
environment?

  A number of the files in the test folder use WIN32, for example, and
  probably ought to use _WIN32... That sort of thing...
 
  For an example see fltk-config --cxxflags.
 
  Statistics: If I counted right (with grep and wc -l) then we have
  181 occurrences of #if ... WIN32 and only 9 of #if ... _WIN32
  (I didn't search in fluid and test dirs, however).
 
  One of them is in FL/Fl_Table.H and 8 are in src/fl_utf.c, which
  are both new files from external sources. IMHO we should
  change _these_ to have identical #if defined ... statements,
  but not change existing ones to _WIN32.
 
  Does anybody know more about this?
 
  I'd guess that Greg or OksiD added those files, and probably developed
  them in a MS VS environment, hence the use of _WIN32.

Yes, that's my assumption, too, and that's why I wrote 'external'.

 From my comments above, I imagine it is clear that I think we should
  actually change everything to _WIN32.
  But I don't feel strongly enough about it to actually make the
  changes...

That's why I asked if anybody knows more about it.

My main point is that we are consistently using WIN32 or _WIN32
everywhere. If we decide to use _WIN32 everywhere, then we must
also change the define in fltk-config and Makefiles (or makeinclude)
or elsewhere. But please don't *mix* both, otherwise we'll maybe get
into trouble.

Perhaps Matt and Mike could tell us more ?

Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev