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:[EMAIL PROTECTED] Thanks, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED] |,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