coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

Part two of the tapestry...

>> I also wanted to weigh in on the shallow-forking thread.  If you do get
>> something to build and it is an active project, don't just fork it.  Send
>> your changes back to the original developer(s).  I've run across a lot of
>> projects no longer actively supported and even one project where the
>> developer was adamant against not having anything to do with a Windows
>> port, but for the most part developers have been really nice about
>> accepting patches for other compilers back into their original projects. 

That's why it's called "shallow-forking".  The intent is that we maintain
as little distance between the original project and our shallow-fork as 
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). 

And, it's not a perfect world. Some projects/authors *don't* care, and won't
be bothered to take the patches, so our process has to allow for that.

When at all possible we're hoping for the upstream project to accept 
patches, but we have to be realistic. 

>> If Visual C/C++ has a GNU like command line front end and I thought there
>> was something like this already in existence with the SFU/SUA project, you
>> can download msys and other Unix like tools (cp, sed, etc.), change some
>> environment variables and build some projects using Visual C/C++.  I do
>> exactly that with the Watcom compiler.  Watcom is nothing like MinGW, but
>> they have a wrapper called owcc and it can be used in conjunction with
>> various GNU tools.  If anyone's interested, I have information on how to
>> set up msys for MinGW or Watcom here:
>> http://www.distasis.com/cpp/msys.htm
>> 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.

Why?

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.


Garrett