For the record, I did try this 2 years ago, with the patch you and
Pierre submitted upstream to MinGW. It compiled but did not link.
So why didn't you report this? I cannot found anything about this, neither
in the tracker nor on the mailinglist. The patch apparently worked fine
for Adam and it worked fine for us.
Well, curiously, apparently that patch made it into MinGW64, and I just
tried again with that compiler-- same result. Compiles but does not
link, because the stub is not in libuuid.
Never heard of such a problem. Can you please give us the technical
details? Which missing symbol, which error message...
That was why we, as a team, decided it was necessary to continue
supporting Visual Studio.
This is not what I remember. I thought we just waited for MinGW to accept
the patch.
Interestingly, your new patch to libos does work with MinGW32, but now
it interferes with the broken patch in MinGW64.
How does it interfere? Please give us the technical details.
Do you see where this is going?
No.
For every piece of Win32 functionality I need that isn't supported in
MinGW, now I'm faced with
MinGW contains most of the Win32 functionality one needs. Especially if
you want to keep supporting older versions of Windows, which I suppose we
want. We don't want a WinVNC or vncviewer which only works on Windows 7+.
I thought you had the same goals, since you have been working on
supporting platforms such as RHEL4?
(a) reverse-engineering a stub for it
Writing a short text file using the MSDN documentation is hardly
reverse-engineering.
(b) writing a CMake compile and link test to verify that it isn't in
MinGW
What's the problem? Writing CMake (or Autotool) tests is the standard
approach when using functionality that is not guaranteed to work on all
platforms. This is the approach we are using for UNIX as well, remember.
and, if so, that the MinGW version isn't broken,
This is seldom. The MS compilers also has bugs.
and (c) conditionally using either the MinGW version of the header (if
it exists) or our header and conditionally linking the MinGW version (if
it exists) or our version.
No, we should either use both header & lib from MinGW, or our internal
implementation.
That isn't exactly an efficient development model.
Having to try every simple change with two different toolchains is worse.
You need to understand that my lack of comfort with MinGW is dictated by
the somewhat hackish approach necessary to get stuff like the above to
work.
I think you consider it as being hackish just because you have little
experience with it.
Enterprise-quality software is not built by hacking.
"Enterprise" means different things to different people. Very often it is
not a positive thing. Take a look at
http://thedailywtf.com/Articles/The-Enterprise-Dependency.aspx (or search
for other Enterprise articles) and you'll see what I mean.
I also understand your lack of comfort with Visual Studio. You haven't
used it continuously for 15 years like I have. I'm not saying that
you're wrong-headed for being uncomfortable with Visual Studio, but
neither should you say I'm wrong-headed for being uncomfortable with
MinGW.
For me, it doesn't have *anything* to do with "feeling uncomfortable".
It's about selecting one toolchain that does the work; supports all of our
platforms. If Visual Studio could run under Linux and generate binaries
for Linux, Solaris, OS X etc, then we could discuss getting rid of MinGW.
But that won't happen.
Comfort level is very important when developing something. I
don't want to feel like I have to patch libos every time I use something
that MinGW doesn't have, and I don't want to have to maintain build
tests for any advanced functionality to determine whether or not it's
present or broken in MinGW.
I feel like I've been more than reasonable and willing to compromise
about this. As the one who's going to be developing WinVNC, I need to
feel like I'm free to do what I need to do to make it work for my
customer, and I am not comfortable using MinGW for WinVNC at this time.
Ok. You don't want to change your habits, but you want to force us to test
build with Visual Studio before every commit? How is this a compromise?
All the extra work would be on us not currently using Visual Studio.
Once things are working properly on W7 and Vista, then we can
re-evaluate.
We can start with making sure WinVNC works with MinGW. If you have no
objections, I'd like to commit the patch.
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
