Re: [MiNT] Version control system selection

[Paul Wratt <paul.wratt@gmail.com>]

On Thu, Jan 7, 2010 at 2:46 PM, Alan Hourihane <alanh@fairlite.co.uk> wrote:
>
> Given we have www.atariforge.org, I'd actually like to start moving our
> Atari projects there and it allows for multiple administrators, with all
> of CVS, subversion and git repo's. Rather than relying on Rob (and/or)
> Frank or me etc to control things. We can open things up to a much wider
> admin audience and have very flexible control.
>
> How does this sound to folk?
>
> PS. I want to get a 1.17 release out asap, once this is done, I'd be
> looking to do a move to www.atariforge.org if there's backing for that.
>
> Alan.
>
this sounds good, and there are some issues the need to be decided
before the final change happens, not just with respect to the repo
used, but the fact that, like the issue of using gcc natively, some
options may be exlusive of native development

I would personally try for a multi-format versioning repo, to allow
native development to still be a practical possibility, but this would
also mean maintaining a usable set of source for a lesser gcc
(according to the discussions on gcc 4.x), and probably Pure C
compatibility.

This however would require some initial work, and then a way to help
maintain it, like a set of users with AHCC/PureC to test sources. In
this respect, a documented, and pre-setup use of ARAnyM and/or one of
the emulators, would keep this a fairly simple task for those
cross-compiling.

At some point in the future it may be even impractical to do this, ie.
maintaining a full native development environment for GCC AND
AHCC/PureC, but I feel that this boundary is not yet a restrictive
line.

With respect to that boundary, and the size and resources used by
modern GNU/GCC and repo's, it may be nescessary to produce a custom
set of gcc and related tool chains, plus other tools, that are "native
only". This would require a collective development approach in order
to be quickly achieved.

I know there are those who would not maintain compaible sources,
simply because they are unhappy with the tools needs to compile them,
not to mention the speed and resource limitations that even ARAnyM
give.

However I think this to can be circumvented easily (for the most part)
by providing an easily referenced "compatibility source" doc. To the
point of including specific MiNT workarounds for current open source
linux projects, anything that requires porting, that uses features not
present in MiNT

With respect to modern development, this may be best implemented in
the libraries used for compiling for the MiNT target, or a dedicated
library that covers this issues in a way that source does not have to
be changed at all (or minimally)

The problem of repo use and compiling natively will not go away, but
only get worse as new versions and software come out, and the longer
it is left the harder it will be to bridge the gap, unless there is
some clear outline as to what can be done about it, or how it should
be handled, even if there is no initial development, something will
get done eventually, and therefore it would be prudent to at least
outline the way forward

Something to think about and discuss until the approaching 1.17 point
release comes about, at least some solid ideas and testing of them may
produce more practical solutions.

Cheers

Paul