coapp-developers team mailing list archive

[ml@xxxxxxxxxxxx]

On Mon, 16 May 2011 15:32:12 +0000
Garrett Serack <garretts@xxxxxxxxxxxxx> wrote:

> possible. The reality is that we need to maintain the files that help us 
> create project files (for which the original author won't care about). 

I wouldn't always bet the original author doesn't care.  Some projects are very happy to take
files from other platforms that can be used to build a project or work with yet another
compiler.  I've sent those types of files to authors in the past and they've been accepted into
projects.

> >> There's no reason why the same technique won't work for other compilers.
> 
> No.
> 
> That's not the way to promote portability. SUA does have such a beast, but
> I wouldn't touch it with a 10 foot pole. If my goal was to get something
> running, and then run away, that might be permissable, but I want nothing
> to do with such a strategy.

Okay, just read the information on what applications and libraries you're currently trying to
port.  Now it makes sense to me why you'd want to avoid SUA tools.  One of my goals is to port
useful applications to Windows that aren't currently available on Windows.  One technique to do
that is to get it running however you can, even if you have to scaffold off of Cygwin or SFU/SUA.  Once an application's ported, it eventually gains critical mass, people find it useful and
want to make it easier to build with their particular compiler tool chain of choice.  Your current list is mainly for programs and libraries that have already been ported to Windows and build or run in some form or another on a Windows machine (even if it's just in SFU).  So, CoApps' goals align more with the second stage where one is trying to make them easier to build with a particular toolset.  

>Because it continues to shut out Windows developers who have zero experience
>in Unix and Unix-like operating systems. Windows developers can be 
>encouraged to participate in open source more, if things are setup in a 
>manner that is familiar and consistent with the work they do on a daily 
>basis.  That means Visual Studio Project Files (... or another compiler 
>they are used to). That means adapt the source to the platform, not the
>platform to the source.

Just curious...  I've been using Microsoft compilers since DOS days and consider myself at least
as knowledgeable in the Win32 interface as the average Windows C/C++ developer, so I would technically consider myself a Windows developer.  Is there documentation easily available
somewhere for how to use Visual Studio Project Files and other parts of the Microsoft toolchain
via command line?  If so, where?  Forcing someone into using a GUI and a particular IDE isn't my
idea of encouraging developers that prefer a command line.  I also strongly believe that command
line versus GUI is not a Unix versus Windows things.  Studies have shown some people absorb and
process information better when presented graphically and other better when presented as text or
orally.  GUI and command line tools are available in both Unix and Windows environments.  I'm in
the group that prefers command line tools.  Is the Coapp project documenting and sharing ways to
make Open Source development on Windows more friendly to that group or only to people who use the
Visual Studio GUI?  Would love to hear about any links to documentation that describe how to use
Microsoft compilers and developments tools strictly via command line or automated scripts.  Thank you.

Sincerely,
Laura
http://www.distasis.com/cpp