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


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?!

> > > 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"?!

> 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 ;)

> 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".

> 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.

> 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.

> Cool.  Let me know when I can download a new version.

I'll give it a try ASAP.

Stipe

mailto:tolj@wapme-systems.de
-------------------------------------------------------------------
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf, NRW, Germany

phone: +49.211.74845.0
fax: +49.211.74845.299

mailto:info@wapme-systems.de
http://www.wapme-systems.de/
-------------------------------------------------------------------

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.2 (Cygwin)

mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS
OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2
nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT
dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv
bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID
AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl
OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ
K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H
g2HyLAEKQIp30Q==
=aYCI
-----END PGP PUBLIC KEY BLOCK-----


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