This is the mail archive of the
mailing list for the Cygwin project.
Re: [cygwin (self-compiled) does not run] Re: cygwin patch&test workflow?
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
A few more notes:
Andy Koppe wrote:
I'd recommend using the CVS sources. Makes it easier to create patchesThe 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
as well. Checkout instructions here: http://www.cygwin.com/cvs.html.
(Those will give you the 1.7 sources.)
So Charles Wilson's script is really needed, I hope it's going to work
for me (see below).
Also, Corinna Vinschen wrote:
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.
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.
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?