[cygwin (self-compiled) does not run] Re: cygwin patch&test workflow?

[Thomas Wolff]

Thanks to all for the hints on compiling cygwin 1.7.0-62 and to Charles 
Wilson for the build script.
Sorry for the late response, and I've modified the subject again because 
this mail comments more on the patch&test workflow.

Actually, the version I produced with the src package (installed, 
non-cvs), which would not run with bash as I reported,
did run with ash or dash, with virtually no other application runnable 
but it was sufficient for testing so the major part of my patch is ready 
now.

A few more notes:

Andy Koppe wrote:
> I'd recommend using the CVS sources. Makes it easier to create patches
> as well. Checkout instructions here: http://www.cygwin.com/cvs.html.
> (Those will give you the 1.7 sources.)
>   
The instructions in cvs.html for building are not really encouraging to 
go that path, if I may say that. Why is the build process completely 
different from installing the src package and just running configure and 
make? Why can the cvs not just bring along the normal make environment 
with it?
So Charles Wilson's script is really needed, I hope it's going to work 
for me (see below).

Also, Corinna Vinschen wrote:
> Just as a side-note for Thomas, it's always a good idea to build from
> CVS since that's the source used for further development anyway.
> Patches against older sources tend to provoke collisions with other,
> already applied changes.
This comment certainly applies to core developers, but for a casual 
patch there is a trade-off. In many projects, cvs snapshots are not 
often runnable or even compilable, so there's not much point in using 
them; maybe that's different for cygwin.

Also, there is a lot of trouble in cvs download. It failed for me a 
number of times:

    * As a side topic, I first got the error cvs [login aborted]: could
      not open /home/towo/.cvspass for writing: No such file or directory
      This is probably due to cvs calling getpwnam of getpwent rather
      than using $HOME as it should, I guess this is an upstream bug.
    * I got this a few times: cvs [checkout aborted]: reading CVS/Tag:
      Not a directory
    * CVS download took *a few hours time* in total. Is that normal?
      (When it stalled the first time after 1 hour, I was not sure
      whether to continue with another checkout or with cvs update already.)
    * On my work PC, cvs connection does not work due to the firewall;
      the proxy feature I found on the web isn't even documented in the
      man page but then it didn't work anyway: cvs [checkout aborted]:
      proxy server 10.159.32.155:8080 does not support http tunnelling


Another issue I wonder about is the compilation turn-around time; I'm 
aware it's long due to the dll building; but also already before the 
actual modified file is being compiled, it takes a lot of time wading 
through a number of makefiles in untouched sub-directories before it 
gets to my construction area.
So you tend to do something else meanwhile (expecting the dll building 
delay) and notice a compilation error much later which makes the 
turn-around time even longer...
Is there a shortcut make target to directly have it compile the modified 
files or at least to go into winsup/cygwin right away, not remaking all 
of newlib first?

Thomas