This is the mail archive of the cygwin-apps@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]
Other format: [Raw text]

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


Stipe Tolj wrote:

I did reverse patching for thre previous packages apache, php, etc
too. Non was objected until know. AFAIK, either you have the orginal
source tree and your patch provides the cygwin specific changes or
oposite. Actually this may you apply the patch to produce the orginal
source tree.

Probably nobody complained because nobody dared look at the monstrous pile-o-code that those two large packages entail. I know I didn't.


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.

Meh. IMO this is a developer prerogative. Do as you like.


Is it really required to patch Makefiles in order to "install" the
cygwin specific README to the ..doc/Cygwin place?! I consider this an
unneading hacking in sources.

Not at all. The method 2 package script does this manually. (e.g part of "./script install" -- which calls 'make install' and then does the "extra stuff".


IMO, sources should be changed as minimally as required.

Yep.


-s linker flag put in place again (was a simple typo). So we get
stripping again. I don't see any needs for port notes to be honest.

Agree (with Stipe). There's no need to repeat, in every package for cygwin, "yep, used --prefix=/usr on THIS package, too!"


8) There is a bug that the file size is declared as u_long, and will be
  truncated for large files.  Why not simply change it to off_t?


any scenario you can give that reproduces this?!

Sure: files larger than 2GiB. off_t == off64_t == long long with cygwin-1.5.x, while "u_long" is just 32 bits IIRC.


--
Chuck


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