Approaches to Windows platform conditions in the code
Luis Lavena
Decided to the list instead of IRC just to have a concrete reference
in the future.
My approach to the work been done in Rubinius has been use MinGW (GCC)
and the need tools. Because of that, all my conditions in C/C++ have
been __MINGW* definitions instead of _MSWIN ones.
But, checking the code for other of these conditional flags found the
later been used.
Should we use MSWIN notations instead of MINGW? Even when MSVC hasn't
been target today?
Thank you for your time.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
Chuck Remes
On Sep 27, 2010, at 12:37 PM, Luis Lavena wrote:
> Howdy.
>
> Decided to the list instead of IRC just to have a concrete reference
> in the future.
>
> My approach to the work been done in Rubinius has been use MinGW (GCC)
> and the need tools. Because of that, all my conditions in C/C++ have
> been __MINGW* definitions instead of _MSWIN ones.
>
> But, checking the code for other of these conditional flags found the
> later been used.
>
> Should we use MSWIN notations instead of MINGW? Even when MSVC hasn't
> been target today?
I can see scenarios where people would want to build and link extensions compiled by MSVC and GCC. I know this can't be supported simultaneously due to different ABIs, but it could be a compile-time choice.
Is it feasible to wrap all uses of MSWIN and MINGW so that both are present in the code but only one is chosen at compile time? Doing so would allow people to compile rbx and extensions with their tool of choice at the expense of more complex macros for Windows.
cr
brian ford
>
> On Sep 27, 2010, at 12:37 PM, Luis Lavena wrote:
>
>> Howdy.
>>
>> Decided to the list instead of IRC just to have a concrete reference
>> in the future.
>>
>> My approach to the work been done in Rubinius has been use MinGW (GCC)
>> and the need tools. Because of that, all my conditions in C/C++ have
>> been __MINGW* definitions instead of _MSWIN ones.
>>
>> But, checking the code for other of these conditional flags found the
>> later been used.
>>
>> Should we use MSWIN notations instead of MINGW? Even when MSVC hasn't
>> been target today?
The configure script needs to emit a define to vm/gen/config.h like
'#define WINDOWS 1' and code should use #ifdef WINDOWS. If WINDOWS
will clash with something else, use RBX_WINDOWS as the identifier.
Cheers,
Brian
>
> I can see scenarios where people would want to build and link extensions compiled by MSVC and GCC. I know this can't be supported simultaneously due to different ABIs, but it could be a compile-time choice.
>
> Is it feasible to wrap all uses of MSWIN and MINGW so that both are present in the code but only one is chosen at compile time? Doing so would allow people to compile rbx and extensions with their tool of choice at the expense of more complex macros for Windows.
>
> cr
>
> --
> --- !ruby/object:MailingList
> name: rubinius-dev
> view: http://groups.google.com/group/rubinius-dev?hl=en
> post: rubini...@googlegroups.com
> unsubscribe: rubinius-dev...@googlegroups.com
Luis Lavena
>
> The configure script needs to emit a define to vm/gen/config.h like
> '#define WINDOWS 1' and code should use #ifdef WINDOWS. If WINDOWS
> will clash with something else, use RBX_WINDOWS as the identifier.
>
Thank you, define WINDOWS will clash as it was used back in 90's to
identify Win95/3.1 and such. Will workout these changes in my
multiverse branch and modify other places with these conditionals to
match.
BTW, in my branch you can feed into configure the --host, used to tell
which compiler or platform to use and skip config.guess
This is needed to support mingw-w64 project: http://mingw-w64.sourceforge.net/
http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS
Thank you again.