This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: [Review - not yet] Re: [ITP] tree
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?!
Nope:
$ 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,
FWIW.
> > 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
upstream.
> > Cool. Let me know when I can download a new version.
>
> I'll give it a try ASAP.
>
> Stipe
> mailto:tolj@wapme-systems.de
Thanks,
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ 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