[Review - not yet] Re: [ITP] tree

Igor Pechtchanski pechtcha@cs.nyu.edu
Thu Dec 18 23:33:00 GMT 2003

On Thu, 18 Dec 2003, Stipe Tolj wrote:

> Igor Pechtchanski wrote:
> >
> > Hmm, I guess it's not that important.  I was just going by what's on
> > <http://cygwin.com/setup.html>, which clearly states that applying the
> > patch *in reverse* should get you the original sources...
> hmm, isn't it the case?!

$ patch -p1 -R < CYGWIN-PATCHES/tree-1.4-1.patch
patching file Makefile
Unreversed patch detected!  Ignore -R? [n] n
Apply anyway? [n] n
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file Makefile.rej

> > > > 3) Any particular reason you have the make and install logs in
> > > >    CYGWIN-PATCHES?  Also, the make log contains a warning that looks
> > > >    suspicious, and the install log shows that "make install" will install
> > > >    files directly into /usr/bin, rather than to a subdirectory.  Also,
> > > >    "make install" will not put the Cygwin-specific README in the right
> > > >    directory.
> > >
> > > historical. AFAIK some people have been doing this for "documentation
> > > purpose" while building packages. The log files may be helpful in
> > > identifing possible problems that someone may observe on his local
> > > installation.
> >
> > True.  It's usually a good idea, though, to be able to install somewhere
> > outside of the main tree (e.g., to recreate the package without polluting
> > your system)...  I'm not sure how important it is that a package is able
> > to do this.
> personally I'm not "required" to put the build logs into the tree.
> That's right.
> What do the others mean. I haven't followed the list for "some while"
> (no comments on this please ;). So I'm for sure out-of-sync regarding
> the "commen behaviour"?!

Umm, I was actually referring to the fact that the installation cannot be
redirected to a subdirectory...  I'm ok with the logs being included,

> > I agree, that's why method 2 became popular, since you don't have to
> > change the Makefiles for some of the Cygwin-specific stuff.  But if you
> > stick with method 1, the users should be able to fully install the package
> > using "make install"...
> now, I'd like to take method 2, but the package does not provide and
> sophisticated autoconf suite, only the raw Makefile. And actually for
> one .c file this is ok ;)

:-)  Take a look at the wtf package...  It's not autotooled either.  And
it uses method 2.

> > Well, I think changing the prefix from /usr/local to /usr is a pretty
> > serious change, in a sense that someone familiar with the package and
> > wanting to install it on their system will download it, run "make; make
> > install", and get the packages in /usr/bin instead of /usr/local/bin where
> > they would expect them.  IMO, it deserves a mention in the port notes, but
> > I'm not going to hold up the release of a package because of this.
> agreed. But don't we consider *all* packages that are installed from
> setup.exe to be "system packages" and hence reside underneath the
> system /usr mount point. In contrast to those who are compiled and
> build by users on their own, which usually go to /usr/local?!?!
> I changed the same semantics for Apache. Apache usualy has its
> instllation layout into /usr/local/apache and we addopted the
> "cygwin-way" to Apache's layout config file to reflect that it is then
> "a system package".

Ok.  It's a minor point, anyway.

> > Well, I don't have any 4G+ files on my system, but it's easy to see that
> > anything with size over 4G will be displayed incorrectly.
> >
> > In fact, most of the LINUX_BIGFILE code should be turned on, except that
> > the types are wrong in some places ("long long" instead of off_t), and
> > Cygwin has no such thing as "struct stat64" - its "struct stat" is 64-bit
> > already.
> ok, I'll give it a try... let's see how far I get.

Well, turns out I was wrong.  The only LINUX_BIGFILE code that should have
been enabled was the printf in line 521...  You could probably just make
it conditional on LINUX_BIGFILE *or* __CYGWIN__...

> > I'll point out that some of the types in "struct _info" are all wrong for
> > Cygwin (mode should be mode_t, uid should be uid_t, gid should be gid_t,
> > and size should be off_t).
> ok, I'll consider this too.

Actually, consider also changing the '#define _LARGEFILE64_SOURCE' in the
LINUX_BIGFILE block to '#define _FILE_OFFSET_BITS 64', removing the
'#ifdef LINUX_BIGFILE...#else' block from "struct _info" (off_t will
already mean the right thing in that case), and submitting this patch

> > Cool.  Let me know when I can download a new version.
> I'll give it a try ASAP.
> Stipe
> mailto:tolj@wapme-systems.de

      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

More information about the Cygwin-apps mailing list