Re: Symbols/shlibs files for Java
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-05-30 15:12, Raphael Hertzog wrote:
> On Mon, 30 May 2011, Niels Thykier wrote:
>>> I would love to generalize the principle of auto-generated dependencies
>>> to cover more than just C libraries but we're far from that, i.e. there's
>>> no infrastructure in place for this and all the code in dpkg-gensymbols
>>> and dpkg-shlibdeps is highly specific to the case of C libraries/binaries.
>>
>> Could we begin refactoring this towards something similar to the
>> $NS::Source::Package setup (e.g. $NS::SymbolsFile::$LANG)? Or would you
>> rather see a different approach to this code-wise
>
> Well, I see the first abstraction higher in the stack: I would like to see
> a dpkg-autodeps. It would call dpkg-shlibdeps as one of the way to obtain
> relevant dependencies for the package being built, but it would also allow
> other package to provides supplementary scripts in /usr/lib/dpkg/autodeps/
> in order to deal with other cases where dependencies can be automatically
> generated.
>
> In other words, you should not even have to explicitly call your java
> helper tool. It would be automatically used.
>
Sounds good to me.
> But of course, if some of those helpers tools are very similar to
> dpkg-shlibdeps/dpkg-gensymbols, then I'm entirely open to make the
> Dpkg::Shlibs:: API more generic.
>
Personally I was considering to use both Perl and Java here, so I
definitely would not mind being able to piggy-back on some existing perl
code.
>> ... and if I discard my desire to record all access qualifiers and such,
>> I think the symbols file is mostly re-usable if we encode things right.
>
> It would be interesting indeed. But I fear there's always going to be
> cases where the mapping will be difficult.
>
Sure, but it would give us something to start from.
> For example, what if a method moves from public to protected?
>
How does C++ handle this? I hope that the access qualifier is not a
part of the name mangling, because that would definitely break stuff
when going from protected to public (which I would believe was a ABI and
API compatible change).
> And I have the feeling that with java you often modify the
> search path for jar, so that mapping dependencies for a java program at
> build time does not mean that at run time it will use the same set of
> jars... (the same applies to C but it's much less common to have lots of
> private libraries that are copies/forks of other libraries).
>
> Cheers,
Actually I think the search path in Debian is rather stable for Java
libraries, especially because we do not allow private libraries copies
of existing libraries if we can avoid it.
But maybe I am misunderstanding of what you are thinking (or I am
blissfully ignorant of such cases :P). Possible exception here would be
the Java Virtual Machines where we have tools for finding a "suitable JVM".
~Niels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJN46OnAAoJEAVLu599gGRCq3MP/idKBubblGYcAkqf3IPkNVEp
ZpGFs/vajZUk9u1CmoHvPma6Qhyd7GXT7UlMe/G1hLd0aMuF9kFin3+UB+aPDciw
sJmerD8UgCPMhRRXnns0FkJwZPxCHdLMoloz0caseQEW48XUZGfzKDKNYJGHxRJZ
oPbTLeshEl4XTBEk6WtVYCBkpNhLs4wUJpJkjU1lHJzwaK/DFI2uF698W6nkLSW+
LfqH3A+mfK5ou9Wpqjmt7N2rzUcTjEXvfX8/57cALaA7DHN6opdVx6Mp6kQcf9zQ
NtPYV7wtHlA15CM/kaRsbkTmN2l/779oZDfMoQJ4MksdRivNoOnCPhz6OrYUQUVa
HR/fmlx+hwgA1AH23E3qW7W58M7ro1Gopd5+leQSVN6TqBuB4KEkDNpLYqTtXF7E
FV6AeFbUS3eybM1O6vZ2ghUk6VQYCFQGqE6JFJL8peKLGKD/j+N0zSVNPIIZL403
xAYSocIDpLafrmXU0OuSpBSvGjKxe2LWPw+ZRm+Mi7T1bLCDsATJFLQvWcb/k3dq
C8lskACyQGjNcXPT5w23R1Wgr3lbi7w95vSmjWiAHiV1Ia3z2qXWNmeMrdjKWeYK
DEqX6tnY1d+sZf0y+PrmAcfvch+HGxCsNa+27wnqVsnOzcltE4ye6LWrYWWtyEol
haeA6inEL5KOAQ2RcgDu
=RjgC
-----END PGP SIGNATURE-----
Reply to: