coapp-developers team mailing list archive

[Elizabeth M Smith <emsmith@xxxxxxxxxxxxxxxxxxxxxxx>]

On 4/9/2010 12:20 PM, Philip Allison wrote:
> Hullo list, and in particular hello Mr. Serack!
> This is a fantastic project idea, but I worry about the concept of
> maintaining "shallow forks", and having to maintain two build
> infrastructures for a project: one for UNIX (my personal choice being
> autotools), and one for the CoApp build environment.  It may simply be
> too early to expect good answers to this sort of question, but is the
> plan to somehow piggy-back off of existing build scripts, by - for
> example - scanning configure.ac, Makefile.am et al and producing at
> least a skeleton of CoApp build script?  This begs for some other
> questions, such as what *is* a CoApp build script anyway?  I assume it
> is a Visual Studio project file, but I've done very little
> professional development on the Windows side of the fence.
> I'm under no illusion that such automatic generation would be simple,
> since the autotools are notoriously difficult to use "correctly" (with
> frequent differences of opinion regarding what constitutes
> correctness), but I also think it would be a mistake to expect
> developers to maintain multiple build systems; IMHO that is one of the
> biggest problems with porting as it currently stands.  "Shallow
> forking" presumably entails third parties - people other than the
> original project developers, perhaps analogous to package maintainers
> in the Linux world - creating and maintaining CoApp build scripts on a
> project's behalf, but it strikes me that such work is best done by
> people who really know the code they're trying to build, and that it
> goes beyond what I for one would consider the remit of a package
> maintainer.
>
> I'm no expert, but I am currently working on a cross-platform project
> which makes heavy use of shared libraries and plugins, using the
> autotools (including libtool) to build using native tools on Linux and
> MinGW on Windows.  The configure.ac and assorted Makefile.am files are
> not easy to get right, and having to recreate their function from
> scratch for a different set of tools - then maintain both over time -
> would be somewhat daunting.
>
> Looking forward to your answers, even if the surface can only be
> scratched at this stage. :)
>
> Regards,
> Phil
>
> _______________________________________________
> Mailing list: https://launchpad.net/~coapp-developers
> Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~coapp-developers
> More help   : https://help.launchpad.net/ListHelp
>    

One thing that you're not addressing here is code.  So you maintain a 
project, and you maintain it for windows.  You do the work to make sure 
it compiles on windows and works on windows and doesn't need changes.

Thank you! (A million times, it's great to see projects that care)

Unfortunately you are the minority.

What "shallow forks" help solve are projects that DON'T maintain for 
windows.
Projects who don't care.
Projects who don't have the developers who know Windows.
Projects who don't have the tools to develop for Windows.
Or don't want to learn the windows API - who expect windows to work 
exactly like unix or linux.

So while I would love to say "leave such work to be done by people who 
really know the code they're trying to build" that is simply not 
feasible for every project.

And while the goal would be to push fixes and things upstream to 
developers - like package maintainers do for linux distributions - the 
bottom line is not all open source projects take windows patches.

How would you address those issues without shallow forks?

Thanks,
Elizabeth M Smith