[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "Cross-compiling for Win32" script vs. rosBE? Debian Win32 port alive?

On Sat, Jun 23, 2007 at 12:03:47AM +0200, Volker Grabsch wrote:
> On Fri, Jun 22, 2007 at 08:50:14PM +0930, Ron wrote:
> > You should be able to do away with the dll.a file now, mingw has
> > been able to link directly to the .dll without an explicit import
> > lib for some time now...
> We know this, but libtool doesn't. So you either leave the *.dll.a
> in you package, or you have yet another thing to patch in all packages
> that depend on that lib.

Ahh.  Yet another reason I'll never use or recommend libtool. ;-)

I really like autoconf, but some of the helpers built on top of it
leave a lot to be desired in the real world.

> > that can help a little, making *.so
> > and *.dll more similar in the way they are used in build scripts.
> Unless you rename the *.dll files into *.so, you'll have to patch the
> "*.files" anyway, thus having no chance to convince the package
> maintainers.

Yeah, and then that will cause its own problems with other things too.

I guess the fundamental problem is that we are pushing the bounds of
'traditional' portability.  Instead of just being portable between
POSIX variants this adds several dimensions of additional incompatibility
that need to be mapped somehow.

On some level I think that's going to be intractable to deal with unless
upstream authors are directly engaged (or their work forked) to handle
systems they don't already support.  With proper upstream support, the
level of patching required for packaging should usually be minimal.
Without it, not only the packaging, but the source itself may need to
be patched.  If not now, then perhaps with some later release.

OTOH, I suspect it is only a matter of time now before we see full
POSIX support in future MS operating systems.  I'm personally growing
in the opinion that until then, users of that system are best and most
painlessly served by treating it as a dumb terminal that gives them
a web browser interface to things running on a Real OS.

That wasn't a practical solution when I first got serious about cross
platform application development, but currently it seems to be maturing
as a viable solution faster than some of the other options.

That still doesn't work for everyone, or everything yet, but its been
quite a while since it hasn't Worked For Me with my real life needs,
and I suspect I'm far from alone in that.

As the user demographics shake out on a scale that might look something
like: Win32 -> MacOS -> Lindows -> Ubuntu -> Debian, this certainly
seems like an appealing solution for developers of EMDebian platforms
that want to support all of these with their products.  Things like
Google's office suite are certainly going to add to the measure of
whether there really is much of a future for 'native' win32 apps.

It's going to be interesting to see how the balance of these approaches
evolves over time.  Especially if rather than going down the POSIX road
MS really do continue to make their browser an inseparable primary
interface to everything the user does on the machine.  Even if all some
people use it for is to launch a 3rd party secure renderer of http
streams ;-)

Anyway, that's just my musing on why win32 ports might not be gaining
the sort of mindshare I'd have though they might by this time, and how
the ground might change from under them if they don't gather speed soon.
I'd still like to see more code more friendly to cross builds, since
the disparity between development platforms and user platforms is sure
to continue to increase.  The win32 platform is a good acid test for
that, since broken assumptions very quickly lead to broken portability ;)

Even if we don't need it now, there are clues in what you learn that can
improve the way we do things...


Reply to: