This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [cygwin (self-compiled) does not run] Re: cygwin patch&test workflow?
On Tue, Oct 27, 2009 at 02:50:25PM +0100, Thomas Wolff wrote:
>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?
It is. I've built cygwin, from scratch, countless times with just a
configure/make. You can't install the dll because windows doesn't allow
you to do so. Otherwise, it works.
>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.
There is not much of a trade-off. You can never be assured that you're
patching in an unmodified section of the code.
But, really, if you want to particpate in *cygwin-developers* you should
be building from CVS. If you want to send a random patch to a mailing
list and hope that someone accepts it then you can always use the cygwin
list. We have a higher standard here than in the main list.
>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.
I'm not aware of many serious projects where cvs snapshots are not
buildable. Even if that was true, that is definitely not the case here
and, so, it's not a valid concern.
>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
Ok, so you had problems. That doesn't mean that everyone has problems.
sourceware.org/cygwin.com has a major projects using cvs. People check
out files all of the time.
If you can't access the source code via CVS then that means that you
can't checkout the source code from CVS and your participation here is
going to be limited. That's just the way it is.
>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?
If you've already built newlib then just cd to the cygwin directory and
type "make".
cgf