This is the mail archive of the cygwin-apps 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: [GTG] Re: [ITA] indent 2.2.9 - C/C++ language source code formatting program

Dave Korn wrote:

> > So the rule is that only top level libs (here libintl8) need
> > to be mentioned in setup.hint::require?
>   Absolutely so.  And you can omit cygwin itself!

Actually no, there are cases where that will give you incorrect or
misleading information.

The problem is that cygcheck has code to prevent outputting a line for
any given library more than once (already_did() in 
Suppose you have a binary called 'app' and two libraries, 'liba' and
'libb'.  Now suppose that app imports functions from both liba and libb,
and liba itself also imports from libb.  If the ordering of the import
data section is just right, you'll run into the situation where
"cygcheck app" prints just:


However, there should also be a "libb" at the first level of indention
because app directly imports from libb as well -- but this line was
suppressed by cygcheck because it had already printed information for
libb.  Thus if you only go by what is at the first level of indentation,
then you would conclude that app's setup.hint should list only liba,
however app has a direct dependance on libb which you have failed to

The practical implication of this may not be severe, because app's
requiring of liba will also give it the libb that it needs.  However, I
wouldn't play games with setup.hint dependencies like that.  I don't
think it's asking too much for the maintainer to know the direct list of
dependencies of his package, which can usually be had simply by looking
at the link command that created the binary.

(I tried to come up with a scenario involving multiple ABI versions of
libb, but in those cases if there are in fact two libb's involved then
the suppression of duplicate lines doesn't happen.  Maybe it's still
possible with longer chains.)


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