This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: "shouted down", "shot down", apologies


Oh yeah -- one other thing.  Most maintainers use separate build and src 
trees.  I don't -- I build "my" packages right in the source directory. 
  However, you *MUST* use separate build and src trees for gcc, 
binutils, and cygwin -- or it won't work.  The "directions" below for 
readline assume the build-in-source-tree model.

I wonder if the following is a useful thing to have in the 
documentation: at set of build instructions (and nothin' but build 
instructions) for each package.  Say, a web page with a bunch of links 
to 10 line txt files (bash scripts?) that each build a given package.

I'm willing to provide that for "my" packages, if somebody else will 
handle the logistics -- and folks think it is a good idea.  (I shudder 
to consider the binutils, gcc, and cygwin scripts -- that python monster 
someone posted earlier today scared even me...)

--Chuck

Charles S. Wilson wrote:

> John Wiersba wrote:
> 
>> So, is the "download source" option for setup.exe useful for 
>> anything?  Can
>> you rebuild (all of) cygwin from it?  What I mean is:  there are these 
>> 80+
>> packages available with setup.exe.  If I download the source for all of
>> them, install the source somewhere, run some build process against it, 
>> will
>> I end up with a working cygwin which is functionally equivalent to the
>> binary packages I downloaded using setup.exe?
>> 
>> -- John Wiersba
> 
> 
> Yes, you can build the tools from the source packages provided as part 
> of the downloads.  However, there is no 'make world' procedure that 
> builds EVERYTHING all in one step.  You have to go into each package's 
> source directory, and do the typical './configure ; make ; make install' 
> procedure.  However, to get EXACTLY the same binaries, you'll need to 
> use the same configuration options that the maintainer used --
> 
> For instance (readline):
>   CFLAGS="-I/usr/include/ncurses" \
>     ./configure --prefix=/usr --with-curses
>   make
>   make shared
>   make examples
>   make test
>   make install prefix=/tmp/usr
>   make install-shared prefix=/tmp/usr
>   make install-examples prefix=/tmp/usr
>   strip /tmp/usr/bin/cygreadline5.dll
>   strip /tmp/usr/bin/cyghistory5.dll
>   (cd /tmp ; tar tvjf readline-X.Y-Z.tar.bz2 usr/)
> 
> and now you have a tarball that *should* be the same as the 'official' 
> one.  In most cases, the maintainers document their build procedures or 
> special config options in /usr/doc/Cygwin/<package>.README
> 
> The exception to this is possibly binutils, gcc, cygwin, mingw.  These 
> packages are kindof intermingled and cgf uses special buildscripts to 
> generate the separate binary tarballs.  I think.
> 
> --Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]