Re: Native windows support (was Re: [Gnu-arch-users] Extension language)

[Joshua Haberman]

On Sat, 2003-10-18 at 14:20, Tom Lord wrote:
>     > From: Joshua Haberman <address@hidden>
> 
>     > I would argue that a native Windows port is highly desirable right now,
>     > and that any version control software that seeks to become pervasive
>     > will need to run on plain Windows.  The cross-platform projects I work
>     > on could never move to a version control system that didn't support
>     > Windows because it would isolate the contributors that use
>     > Windows.  
> 
> 
> What you describe is a shop with these characteristics:

I'm actually thinking in terms of a free software context.  I hope I
have not given you the false impression that I am thinking in terms of a
company.

The main project I work on is Audacity
(http://audacity.sourceforge.net), a cross-platform audio editor that
runs on Windows, Linux, and Mac OS X.  There are developers and
significant numbers of users on each platform.

In general, I prefer to commit the time of becoming intimately familiar
with a program -- in effect subscribing to it as my personal solution to
a certain problem -- to programs that are platform agnostic enough that
they can serve me on whatever platform I find myself working on.  For
example:

- I have subscribed to Python as my favored programming language for 
non-performance-critical use, and C++ or C for performance critical use,
because they are available and well-supported for any platform
- I have subscribed to wxWindows as my favored GUI toolkit because it is
available for most any platform
- I have subscribed to Vim as my favored editor and it is available on
every platform (of course other are too, but it's the one I chose)
- likewise CVS for version control

Do you see where I'm going with this?  No matter what platform is placed
in front of me, I can be up and running writing applications with Vim,
Python or C++, wxWindows, using CVS for version control in almost no
time.  I have platform-agnostic requirements.  I am thinking of buying a
PowerBook sometime this year, my first Mac ever, and I won't miss a beat
because everything I've come to call my own already runs there.

>       *) some programmers working on unix-family platforms
>         *) some programmers working on msft-line platforms
>         *) a shared line of development between the two

Yes.

> Developers specializing in work on msft platforms are likely to be
> already trained and ready to go using msft platform vc tools, horrid
> though those tools may be.

SourceSafe doesn't really enter into the picture for my situation.

> You might reply saying "Yes, but I want the msft developers to have
> all the benefits of arch," to which there are three replies:
> 
>   1) Your company will be more competitive in the labor market if you
>      let the msft developers stick to things like "visual source
>      [un]safe".

Working on free software we don't think about such things.  :)

>   2) Now you are beginning to understand why killing msft platforms is
>      ultimately good for technology consumers:   the costs of making
>      everything work well on both unix-family and msft-line platforms 
>      tends not to fall well below the demand and the cost of
>      developing good and lasting solutions on unix-family is
>      distinctly lower.

I am afraid this doesn't really affect the reality of living in a
Microsoft-dominated world and being faced with Microsoft operating
systems frequently.

>   3) I hear that Common Lisp provides nice file system abstractions
>      that work across platforms.   It could be an interesting exercise
>      to try to make a CL port of arch.

I am not familiar with Common Lisp, but wxBase (the non-GUI core of
wxWindows) has similarly useful abstractions for dealing with files and
filenames in a platform-independent way.  See:

http://www.wxwindows.org/manuals/2.4.1/wx144.htm

> It's a nice fantasy to wish for a world in which platforms and
> applications were independent, but as they say, "If wishes and buts
> were candy and nuts....."

Audacity runs today and is in widespread use on three different
platforms.  We demand more system-specific support than arch ever will,
since audio i/o APIs are significantly different from platform to
platform.  We also use eight third-party free software libraries, all of
which are also portable to all our target platforms:

wxWindows
expat
libid3tag 
libsndfile
soundtouch
libmad
libogg
libsamplerate
libvorbis
portaudio

It takes work, but the result is worth it.

> I am curious: what is the _current_ solution you use for
> multi-platform development?  Is it ad hoc?  Nonexistent? Is it CVS?
> If it's CVS, then the existing arch<->CVS bridges already give you a
> handy solution.

It's CVS.  My gut reaction is that the hassle of maintaining two
version-control systems would outweigh the benefits of using arch.

Josh