Making ORBit work with MS VS compilers

[Marcelo Vanzin]

Hello all,

I decided to take a look at how to change ORBit so it works properly
with the VisualStudio compilers. I think I have a pretty good idea of
what needs to be done (I've done similar work for another library
recently), and I've played with the sources a bit and it shouldn't be
too hard.

I have a few questions, though:

- I decided to start with libIDL, since it's much, much smaller, to
get an idea of how the contribution process works and all. I've made
the changes, and I just need to install the Vista SDK at home to try
it out on Windows (I've tested similar things on my work computer
already, where I have VS 2003 available). Is this the right list to
send things about libIDL? I'm assuming it's somewhat "part" of ORBit.

- How should I send patches? Should I just attach the gzipped output
of "svn diff", or is there a tracker for patches?

- A more ORBit-specific question: there are a lot of functions in
several headers protected with a "ORBIT2_INTERNAL_API" define. Are
these *really* supposed to be internal to ORBit only (I know at least
a few of them are called in the test programs), or do other apps also
rely on these functions?

- Are there a few recommended apps/libraries for which I should get
the sources so I can make sure I didn't break things with my changes?

BTW, the instructions at
http://www.gnome.org/projects/ORBit2/download.html about how to get
the sources are terribly outdated. Someone should just provide a
source to the GNOME devel page instead. :-) Thanks for any help!

--
Marcelo Vanzin
mmvgroups@...
"Life's too short to drink cheap beer."
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Tor Lillqvist]

>  I decided to take a look at how to change ORBit so it works properly
>  with the VisualStudio compilers

Great! That will be muchly appreciated. (I assume you are not just
talking about setting up VS projects, fixing inclusions of stuff like
unistd.h that VS doesn't have, etc here? You do know that there are
deeper technical reasons related to the capabilities of the object
file format on Windows that explain why ORBit2, and code produced by
its IDL compiler currently can be compiled and linked ony with the GNU
toolchain ("mingw") for Windows, with the
--enable-runtime-pseudo-reloc flag, right?)

.> Is this the right list to send things about libIDL? I'm assuming it's
> somewhat "part" of ORBit.

I think this is a good list, yes. I am not immediately aware of any
other users of libIDL than ORBit2.

>  - How should I send patches? Should I just attach the gzipped output
>  of "svn diff", or is there a tracker for patches?

Open a bug on bugzilla.gnome.org and attach the patch((es) there.
Don't bother zipping them. Just attach diff -u output as text. If you
submit whole new files, you can combine them into a zip archive, but
don't do this for single files please.

>  - A more ORBit-specific question: there are a lot of functions in
>  several headers protected with a "ORBIT2_INTERNAL_API" define. Are
>  these *really* supposed to be internal to ORBit only (I know at least
>  a few of them are called in the test programs), or do other apps also
>  rely on these functions?

They are internal, I would assume, yes. (And in an ideal world they
wouldn't even be mentioned in the public header files, but only in
private headers that aren't installed by "make install".) Please do
create .def files that list only the publicly exported symbols and
submit also them to bugzilla. The GNU toolchain build for Win32
currently relies on just exporting all public symbols, so also the
private functions get exported from the DLLs.

>  - Are there a few recommended apps/libraries for which I should get
>  the sources so I can make sure I didn't break things with my changes?

Hopefully the test programs included with ORBit2 should be enough to
test its functionality.

If you want to test with some "real" application, I think that
unfortunately you have to go quite higher up in the GNOME stack to get
some non-"test" application. Zenity? That would mean rebuilding at
least libbonobo, GConf, libbonoboui, gnome-vfs probably, libgnome and
libbonoboui (from memory, I am probaby forgetting some libraries)
against your new ORBit2 Win32 API before you can build something like
zenity. That stuff has obviously never been built for Win32 with
Microsoft's compiler before, either, just mingw, so there is some
porting effort involved of the trivial-ish kind, adding configure.in
tests for unistd.h, adding #ifdef HAVE_UNISTD_H, etc.

In your patches, please don't use just #ifdef _MSC_VER to
conditionalise your changes. Use a more descriptive feature test
macro, like #ifdef ORBIT2_WIN32_PORTABLE_API, so that one can compile
with your changes also with gcc and still get code that is API and ABI
compatible with yours.

And please, do follow the coding style conventions of the surrounding
code. Tab stops are at eight column intervals. (And indentation offset
is a different thing from tab stop width.) But you probably know this.

--tml
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Marcelo Vanzin]

Hi Tor, thanks for the comments.

On Sat, Mar 15, 2008 at 1:15 AM, Tor Lillqvist <tml@...> wrote:
>  Great! That will be muchly appreciated. (I assume you are not just
>  talking about setting up VS projects, fixing inclusions of stuff like
>  unistd.h that VS doesn't have, etc here? You do know that there are
>  deeper technical reasons related to the capabilities of the object
>  file format on Windows...

Yes, I know that's not all it takes. In fact, I don't even have VS
available at home, I only have the SDK (compiler, linker, headers,
etc) and will try to make do with that, otherwise I'll have to vnc
into my work machine.

>  They are internal, I would assume, yes. (And in an ideal world they
>  wouldn't even be mentioned in the public header files, but only in
>  private headers that aren't installed by "make install".)

I'm currently testing things on Linux using GCC's visibility support
(which is not entirely the same, but helps out a bit until I set up
the Windows stuff). The problem with people calling those functions is
that they have to be exported in the library. A few of them I already
had to export due to the test code.

> Please do
>  create .def files that list only the publicly exported symbols and
>  submit also them to bugzilla.

Hmmm, that's one of the issues, .def files by themselves do not work.
They work for functions (ignoring the fact that it's a pain to keep
the .def files synced with the code, especially when you have
auto-generated code as in ORBit), but they don't work for data. For
data, you need the entry in the .def file *and* a
"__declspec(dllimport)" annotation in the header, or it won't work
with MS's linker. The fun part is that the annotation cannot be there
when compiling the DLL, only when linking to it, which requires lots
of macro-fu.

>  Hopefully the test programs included with ORBit2 should be enough to
>  test its functionality.

I'll download a few GNOME things just to make sure things work on
Linux. Not very worried about GNOME working on Windows at this point,
since this is not really my end goal. :-)

>  zenity. That stuff has obviously never been built for Win32 with
>  Microsoft's compiler before, either, just mingw, so there is some
>  porting effort involved of the trivial-ish kind, adding configure.in
>  tests for unistd.h, adding #ifdef HAVE_UNISTD_H, etc.

That's a point that I forgot to mention in my original message... do
you know of any good autoconf/automake tutorials I could read?
Everytime I look at those .in files, they look like line noise to
me...

>  In your patches, please don't use just #ifdef _MSC_VER to
>  conditionalise your changes. Use a more descriptive feature test
>  macro, like #ifdef ORBIT2_WIN32_PORTABLE_API, so that one can compile
>  with your changes also with gcc and still get code that is API and ABI
>  compatible with yours.

Noted. I will need Win32-specific code, though. (I've generally relied
on _WIN32, which is set by MS's compiler, and I see libIDL uses
G_PLATFORM_WIN32. Would one of those be OK? Are gcc for cygwin/mingw
compatible with MS's extensions like the __declspec stuff?)


--
Marcelo Vanzin
mmvgroups@...
"Life's too short to drink cheap beer."
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Tor Lillqvist]

>  The problem with people calling those functions is
>  that they have to be exported in the library.

You mean that upper level code in other libraries *do* call the
functions commented as "internal"? (And presumably have done so, then,
for several GNOME release cycles?)

In that case then, they clearly aren't actually internal, but part of
the de facto API.

> Hmmm, that's one of the issues, .def files by themselves do not work.
>  They work for functions (ignoring the fact that it's a pain to keep
>  the .def files synced with the code

Yes, I know. Back when I used hand-maintained .def files in GLib and
GTK+ it was a pain. Nowadays, luckily, .symbols files are used for
GLib and GTK+ on Linux, too (and thus get maintained by others, too),
and the .def files are generated from the .symbols files.

>, they don't work for data. For
>  data, you need the entry in the .def file *and* a
>  "__declspec(dllimport)" annotation in the header,

Ah yes, that is a pain. There are a couple of variables in the API of
GLib and GTK+, and they require an ugly ifdef mess in the header.

> That's a point that I forgot to mention in my original message... do
>  you know of any good autoconf/automake tutorials I could read?

There is a book called "GNU Autoconf, Automake and Libtool.

>  (I've generally relied on _WIN32, which is set by MS's compiler,

and by gcc, too

>  and I see libIDL uses
>  G_PLATFORM_WIN32. Would one of those be OK?

G_PLATFORM_WIN32 covers Cygwin, too. G_OS_WIN32 means "native" Win32
and should be equivalent (but more "GLib style") to _WIN32.

I think we want to make the style of API/ABI used a configuration
option, at least initially.

>  Are gcc for [cygwin/] mingw
>  compatible with MS's extensions like the __declspec stuff?)

Yes.

--tml
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Jules Colding]

Hi Marcelo,

On 15/03/2008, at 19.47, Marcelo Vanzin wrote:

> Hi Tor, thanks for the comments.
>
> On Sat, Mar 15, 2008 at 1:15 AM, Tor Lillqvist <tml@...> wrote:
>> Hopefully the test programs included with ORBit2 should be enough to
>> test its functionality.
>
> I'll download a few GNOME things just to make sure things work on
> Linux. Not very worried about GNOME working on Windows at this point,
> since this is not really my end goal. :-)

Please consider at least build testing e-b. It really gets around in  
the corners of the API.

http://svn.42tools.net/

Best regards,
   jules


_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Tor Lillqvist]

> Please consider at least build testing e-b. It really gets around in
>  the corners of the API.

Btw, if you happen to have some (otherwise simple) test programs that
test expected behaviour not tested by the existing test programs in
ORBit2, it would be a good idea to add them to the ORBit2 sources.

--tml
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Jules Colding]

On 16/03/2008, at 14.13, Tor Lillqvist wrote:

>> Please consider at least build testing e-b. It really gets around in
>> the corners of the API.
>
> Btw, if you happen to have some (otherwise simple) test programs that
> test expected behaviour not tested by the existing test programs in
> ORBit2, it would be a good idea to add them to the ORBit2 sources.

Yes, I know. Unfortunately all of my non-trivial code depends on  
brutus IDLs and are thus unsuitable for the test suite.


BR,
   jules


_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Marcelo Vanzin]

Hi Tor,

On Sun, Mar 16, 2008 at 12:54 AM, Tor Lillqvist <tml@...> wrote:
> >  The problem with people calling those functions is
>  >  that they have to be exported in the library.
>
>  You mean that upper level code in other libraries *do* call the
>  functions commented as "internal"? (And presumably have done so, then,
>  for several GNOME release cycles?)

I mean I don't know. I was asking, because my initial thought is not
to expose those functions in the Windows DLL. But if people use them,
then that may not be the best approach.

>  Yes, I know. Back when I used hand-maintained .def files in GLib and
>  GTK+ it was a pain. Nowadays, luckily, .symbols files are used for
>  GLib and GTK+ on Linux, too (and thus get maintained by others, too),
>  and the .def files are generated from the .symbols files.

I took a look at the glib sources, and to me the .symbol approach
looks just as unappealing as .def files.

>  Ah yes, that is a pain. There are a couple of variables in the API of
>  GLib and GTK+, and they require an ugly ifdef mess in the header.

The real problem is with exported data. The only way not to have the
messy macros for exported data is to *not* include the header file
defining the variable in the .c file that actually contains the
declaration, otherwise the VC compiler will complain about
"conflicting dll linkage" or something like that. It's a pain, but I
haven't really figured out a better approach yet...

I submitted a patch for libIDL
(http://bugzilla.gnome.org/show_bug.cgi?id=522697) which uses the
macro approach. It's somewhat similar to glib's macros, although a
little bit simplified. If you could take a look and see what you think
about taking that approach, it would be really appreciated.

>  > That's a point that I forgot to mention in my original message... do
>  >  you know of any good autoconf/automake tutorials I could read?
>
>  There is a book called "GNU Autoconf, Automake and Libtool.

Well, I'll stick to custom makefiles until I have time to figure out
all that. :-)

>  >  Are gcc for [cygwin/] mingw
>  >  compatible with MS's extensions like the __declspec stuff?)
>  Yes.

So in the worst case, my current patch won't do any harm. Haven't
tested with gcc on cygwin, though...

Jules: I'll take a look at e-b, thanks for the suggestion.


--
Marcelo Vanzin
mmvgroups@...
"Life's too short to drink cheap beer."
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Tor Lillqvist]

> I took a look at the glib sources, and to me the .symbol approach
>  looks just as unappealing as .def files.

True, but they are maintained not just for Win32 reasons, so there are
more people who keep them up-to-date.

>  (http://bugzilla.gnome.org/show_bug.cgi?id=522697)

Will have a look.

--tml
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Michael Haubenwallner]

On Fri, 2008-03-14 at 21:15 -0700, Marcelo Vanzin wrote:
> Hello all,
>
> I decided to take a look at how to change ORBit so it works properly
> with the VisualStudio compilers. I think I have a pretty good idea of
> what needs to be done (I've done similar work for another library
> recently), and I've played with the sources a bit and it shouldn't be
> too hard.

You might want to have a look at parity[1] (formerly called wgcc[2]) to
build native Windows binaries using VisualStudio compilers.

We are successfully using ORBit2-2.14.2 (libIDL-0.8.6, glib-2.12.4) with
our native Win32 application, while the build environment (also for the
application) still is unix like: on Interix, using autotools.

Unfortunately, our patches for the makefiles assume when build
environment is Interix, the output is native Win32 using parity, so
currently they don't allow Interix binaries...

[1] http://sourceforge.net/projects/parity 
[2] http://interix-wgcc.sourceforge.net/

/haubi/

_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Tor Lillqvist]

> You might want to have a look at parity[1] (formerly called wgcc[2]) to
>  build native Windows binaries using VisualStudio compilers.

Is there any webpage give a higher-level technical description of what
parity is? Apparently it is (yet another) wrapper for the Microsoft
toolchain to make their command-line interface be more like that of
gcc? Briefly looking in the sources, it apparently also then
additionally supports some of the Linux run-time linker features, like
LD_PRELOAD? (But the usefulness of that when still using PE format
executables (.exe and .dll) is somewhat limited, isn't it?)

Hmm, the ReleaseNotes.txt says "It relies on the presence of a UNIX
Layer for Windows such as Interix, Cygwin or MinGW" which doesn't make
sense, as MinGW is not a UNIX Layer in the same sense as Interix or
Cygwin at all. On the other hand right after is says "This results in
pure and native Windows Libraries and Executables". So I guess the
mention of Interix and Cygwin only refers to the environment in which
to run the toolchain, not the resulting executables?

Anyway, for ORBit2 and code generated by its IDL compiler, the
interesting question is, do you have some workaround for the object
file format problem, i.e. something similar to GNU ld's
--enable-runtime-pseudo-reloc? Could this workaround implementation be
"extracted" from parity and perhaps used also in a purely Visual
Studio environment without the rest of parity?

--tml
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Markus Duft]

Tor Lillqvist <> wrote:
>> You might want to have a look at parity[1] (formerly called wgcc[2])
>>  to build native Windows binaries using VisualStudio compilers.
>

First of all, Hi :)

I'm the author of parity.

> Is there any webpage give a higher-level technical description of what
> parity is? Apparently it is (yet another) wrapper for the Microsoft
> toolchain to make their command-line interface be more like that of

There is no webpage (yet), and yes, it's a wrapper around Microsoft's
tools, to make it look (and as far as possible also behave) like gcc.

> gcc? Briefly looking in the sources, it apparently also then
> additionally supports some of the Linux run-time linker features, like
> LD_PRELOAD? (But the usefulness of that when still using PE format
> executables (.exe and .dll) is somewhat limited, isn't it?)

Yes it adds support for LD_PRELOAD and such things, but that doesn't
influence compat to all other windows libraries. Everything built with
parity can be linked with any other native thing (the only thing is,
that the naming of the files is different. The .so files are the import
libs to link to (normally .lib). This was done this way to make things a
lot easier while porting...)

This means you can just add such a parity-built .so file to the linker
command line in visual studio and it will work. All the things that
parity adds are really private for each binary that is linked.

>
> Hmm, the ReleaseNotes.txt says "It relies on the presence of a UNIX
> Layer for Windows such as Interix, Cygwin or MinGW" which doesn't make
> sense, as MinGW is not a UNIX Layer in the same sense as Interix or
> Cygwin at all. On the other hand right after is says "This results in

Oops, should be MSYS instead of MinGW, although i didn't try it there.
Interix is the best tested one, there i use it all the time.

> pure and native Windows Libraries and Executables". So I guess the
> mention of Interix and Cygwin only refers to the environment in which
> to run the toolchain, not the resulting executables?

Exactly, interix is used to run parity (which most likely is built as an
interix executable). The resulting binaries are pure win32 (btw: 64 bit
are not supported so far...).

>
> Anyway, for ORBit2 and code generated by its IDL compiler, the
> interesting question is, do you have some workaround for the object
> file format problem, i.e. something similar to GNU ld's
> --enable-runtime-pseudo-reloc? Could this workaround implementation be
> "extracted" from parity and perhaps used also in a purely Visual
> Studio environment without the rest of parity?

Huh? What file format problem? I ported Orbit2 and use it within a
somehow big application :) haven't had problems so far.

Hope that helps a little, if you have questions, i'm happy to answer!

Cheers, Markus

>
> --tml

_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Tor Lillqvist]

> Huh? What file format problem? I ported Orbit2 and use it within a
> somehow big application :) haven't had problems so far.

Hmm. Did you compile with optimization? If I recall correctly, the
problem only shows up with optimization, at least when using the GNU
toolchain. My memory of the technical details is a little fuzzy, let
me check if I can find old mail about this subject. If I recall
correctly it is possible to demonstrate the problem with a quite
minimal test case that doesn't involve ORBit2, I'll go hunting for a
such.

(Of course, it is possible that newer versions of the MS toolchain are
smart enough so that the problem doesn't exist when using them. That
would rock!)

Hmm, there is a description of the problem in the GNU ld
documentation, search for the documentation for --enable-auto-import
and --enable-runtime-pseudo-reloc in the ld info file. I will try the
minimal test cases presented there with gcc and various MSVC versions.

--tml
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Marcelo Vanzin]

Hi Michael,

On Mon, Mar 17, 2008 at 2:31 AM, Michael Haubenwallner
<michael.haubenwallner@...> wrote:
>  You might want to have a look at parity[1] (formerly called wgcc[2]) to
>  build native Windows binaries using VisualStudio compilers.
>
>  We are successfully using ORBit2-2.14.2 (libIDL-0.8.6, glib-2.12.4) with
>  our native Win32 application, while the build environment (also for the
>  application) still is unix like: on Interix, using autotools.

That's really interesting, and thanks for the tips - parity looks like
it could help me with the libtool issues I'm having with MSVC. :-)

Since you've been using ORBit on Windows, did you have to make any
modifications to libIDL? I moved into playing with the IDL compiler
and ran into issues because of libIDL. Pretty trivial changes, but the
code out of SVN did not work.

--
Marcelo Vanzin
mmvgroups@...
"Life's too short to drink cheap beer."
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Tor Lillqvist]

> That's really interesting, and thanks for the tips - parity looks like
>  it could help me with the libtool issues I'm having with MSVC. :-)

Hmm, so you are planning on still using libtool even if you compile
with MSVC? I thought your plan was to build it completely from the
IDE, i.e. create project and solution files etc. Or at least to use
nmake and its makefiles. Is it then only because you want to be able
to use the Visual Studio debugger that you want to compile ORBit2 for
Windows with the MS compiler? You do know that one can already build
it using mingw, right?

Or is your interest mainly in being able to build ORBit2-*using* code
in Visual Studio; whether ORBit2 itself then has been built with a
Unixish make+libtool+cl.exe or from the IDE is irrelevant?

Using libtool, and relying on some Unixish build environment like MSYS
or Interix, is bound to mean that at least some potential developers
won't be interested in taking part. For ORBit2 it perhaps is not that
important as it is more or less "ready" already, but especially for
working on GTK+ and GTK+-based applications like GIMP it would be nice
to attract new developers, even such that use Visual Studio IDE only,
and would be scared away by anything Unixish...

--tml
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Michael Haubenwallner]

On Mon, 2008-03-17 at 21:08 -0700, Marcelo Vanzin wrote:
<snip>
> Since you've been using ORBit on Windows, did you have to make any
> modifications to libIDL? I moved into playing with the IDL compiler
> and ran into issues because of libIDL. Pretty trivial changes, but the
> code out of SVN did not work.

(Markus, correct me if I'm wrong)

Don't know how you build libIDL - we do a full autoreconf of any package
to be built with parity, currently with
      * patched libtool-1.5.24 to know about parity and winnt
        [libtool-1.5.24-parity.patch]
      * patched autoconf-2.59 to flip windows line endings in configure
        [autoconf-winnt-flip.patch]
      * vanilla automake-1.9.6
      * there still might be another patch required for any just-created
        configure (we do it in a generic way): Any 'rmdir conftest'
        needs to be 'rm -rf conftest'.
        You can apply this patch snippet as often as possible to
        configure:
       
        --- configure    2005-06-10 10:00:00.000000000 +0000
        +++ configure    2005-06-10 10:00:00.000000000 +0000
        @@ -1,1 +1,1 @@
        -    rmdir conftest
        +    rm -rf conftest

Using this procedure (maybe I forgot something), the patches required to
build native windows binaries of many packages using autotools can be
kept small - they normally just need to handle windows specific things
without touching the build environment. Even when calling just built
winnt executables with interix path-arguments, parity's runtime wrapper
should correctly convert them to windows style.

Attached are the patches for libtool and autoconf, as well as our patch
for libIDL-0.8.6 [libIDL-parity.patch], packed into
[libIDL-patches.tar.bz2].
Now we can build libIDL this way:
(NOTE: the autotools as well as parity are built for i586-pc-interix*)

$ export CC=parity.gnu.gcc
$ export CXX=parity.gnu.gcc
$ export LD=parity.gnu.gcc
$ ./configure --build=i586-pc-winnt --host=i586-pc-winnt --prefix=...
$ gmake
$ gmake install

But this does not mean you can use parity only as "cross"-compiler from
interix to winnt - parity should be able to build itself as winnt
executable, so you could use parity from within VisualStudio. Although
you don't have the path-conversion feature then - which you should not
need in this case.

HTH,
/haubi/

PS: please keep Markus Duft on CC, he's not on the list (yet)


_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Markus Duft]

Michael Haubenwallner <mailto:michael.haubenwallner@...> wrote:
> On Mon, 2008-03-17 at 21:08 -0700, Marcelo Vanzin wrote:
> <snip>
>> Since you've been using ORBit on Windows, did you have to make any
>> modifications to libIDL? I moved into playing with the IDL compiler
>> and ran into issues because of libIDL. Pretty trivial changes, but
>> the code out of SVN did not work.
>
> (Markus, correct me if I'm wrong)

Ok :)

>
 <snip>
>
> But this does not mean you can use parity only as "cross"-compiler
> from interix to winnt - parity should be able to build itself as winnt
> executable, so you could use parity from within VisualStudio. Although
> you don't have the path-conversion feature then - which you should not
> need in this case.

I don't know if it's that easy to tell visual studio to use parity
(haven't tried). But: the path conversion is still available, also when
parity is a native windows build. It does this by trying to load the
interix dll for path conversion dynamically. Note that parity also tries
to load cygwin1.dll to convert paths, if interix fails...

Also there are of course Visual Studio Project files for building parity
as native windows executable. (which also gives the possibility to build
the "Managed *" Configurations, which include the graphical
configuration editor :)

Cheers, Markus

>
> HTH,
> /haubi/
>
> PS: please keep Markus Duft on CC, he's not on the list (yet)

_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Marcelo Vanzin]

Hi Tor,

On Tue, Mar 18, 2008 at 1:06 AM, Tor Lillqvist <tml@...> wrote:
>  Hmm, so you are planning on still using libtool even if you compile
>  with MSVC? I thought your plan was to build it completely from the
>  IDE, i.e. create project and solution files etc.

Sorry if I wasn't that clear. I'm interested in building it with the
MS VC toolchain, not necessarily with Visual Studio. :-) I don't even
have VS (unless, of course, I get my employer to allow me to work on
it, then I'd have access to VS - but even then, we don't use VS to
build anything at work, we actually use cygwin, but with MS's
compilers).

> Or at least to use
>  nmake and its makefiles. Is it then only because you want to be able
>  to use the Visual Studio debugger that you want to compile ORBit2 for
>  Windows with the MS compiler? You do know that one can already build
>  it using mingw, right?

I know it's possible to build it with mingw. But I started looking at
this because we're looking for something like ORBit for a project at
work. We don't want C++, and so far we've been playing with ILU (which
I really don't like very much, even though it works, for some value of
works). And at work, on Windows, we only use MS compilers, and I don't
see that changing anytime soon.

I actually have very little experience with VS (even less than with
autotools), so at this point it's much easier for me to just put
together a few custom makefiles to make sure I can compile things and
they work.

>  Using libtool, and relying on some Unixish build environment like MSYS
>  or Interix, is bound to mean that at least some potential developers
>  won't be interested in taking part.

Yeah, I understand that. It's just that I'm not really a Windows
developer, and my interest in doing this is not related to integration
with VS, just in using MS's compiler toolchain.

--
Marcelo Vanzin
mmvgroups@...
"Life's too short to drink cheap beer."
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Michael Haubenwallner]

On Tue, 2008-03-18 at 11:09 -0700, Marcelo Vanzin wrote:

> Hi Tor,
>
> On Tue, Mar 18, 2008 at 1:06 AM, Tor Lillqvist <tml@...> wrote:
> >  Hmm, so you are planning on still using libtool even if you compile
> >  with MSVC? I thought your plan was to build it completely from the
> >  IDE, i.e. create project and solution files etc.
>
> Sorry if I wasn't that clear. I'm interested in building it with the
> MS VC toolchain, not necessarily with Visual Studio. :-) I don't even
> have VS (unless, of course, I get my employer to allow me to work on
> it, then I'd have access to VS - but even then, we don't use VS to
> build anything at work, we actually use cygwin, but with MS's
> compilers).

Then you really should consider trying parity. Although we're on
Interix, there should be no reason to not operate on Cygwin as build
environment.

/haubi/

_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Tor Lillqvist]

> Then you really should consider trying parity. Although we're on
>  Interix, there should be no reason to not operate on Cygwin as build
>  environment.

Maybe with parity it's different but at least when building stuff on
Windows using the "normal" autofoo and libtool mechanism, I definitely
recommend staying away from Cygwin and using MSYS instead.

As Cygwin comes with "normal" headers for the libraries it includes in
/usr/include, and libraries in /usr/lib, with Cygwin there is always
the risk of confusing Cygwin headers with the headers of depencencies
you really want to use, and the risk of confusing Cygwin libraries
with the libraries you really want. At least, that is my experience
from back when I built the GTK+ stack for Windows on Cygwin, using its
gcc with the -mno-cygwin switch.

No such risk with MSYS. Even if MSYS technically is a fork of Cygwin,
MSYS is "just" the runtime where tools like sh, awk, sed and perl run,
not a development target by itself. Also, the main MSYS feature, i.e.
the automatic mangling of command-line file name parameters and
PATH-like environment variables fron Unix form to Windows form is
quite useful. Cygwin does not do this automatically, you might have to
insert cygpath calls here and there.

With extreme care it is possible to use Cygwin, sure. For instance the
way to build Mono on Windows with gcc is to use run the build on
Cygwin and use gcc -mno-cygwin. But I bet they have had to be quite
careful when constructing their Makefiles.

--tml
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list