[fpc-devel] Summer of code collaboration

[Marco van de Voort]

In our previous episode, Jonas Maebe said:
> > Then we would still have the problem of the outdated tools. Maybe we could write Pascal based substitutes for them that only need to handle the cases of compiler/rtl compilation...
> 
> The only problem I'm aware of is cp copying the read-only attribute under
> Windows and refusing to overwrite such files, resulting in problems when
> installing examples from the packages dir from a non-exported svn checkout
> over a previous install.  That problem does not affect either the compiler
> or the RTL.

That, and its consequence should not be underestimated, it requires an
export that can be terribly slow on a work machine with anti-virus. Luckily
if you don't build real releases, you can avoid it by equating it to echo
(as described in the buildfaq)

Some others:

1) The need to have manifests for install and patch, since
anything with install or setup or patch triggers UAC (fixed, but can be
confusing for end-users that copy these files over a network drive, binaries
with "downloaded from network" bit get the UAC prompt again, which means a
horrible GPF for a non GUI program.

2) the fact that nearly every toolchain (commercial or not) installs an own
version of make, and typically adds its own dir to the $PATH. Not in the
least our direct competitor, Embarcadero that has a totally incompatible
make.  This is also why the bootstrap for fpmake, if we ever come to that
should not be make based.

3) Same in the case Mingw, cygwin also for other tools than make. Also 3rd
party development systems as dev-* and freebasic that package these tools.

4) In some circumstances, even if cygwin is in the path AFTER fpc, suddenly
parts may be executed under cygwin's shell which fails because cygwin's
shell prefers its own tools.  I think that this is because make (our
makefile's?) behaviour changes when sh.exe is found. Never really got the
details of this.