Re: java dependency substvars and native compilation
On Thu, May 03, 2007 at 08:45:47AM +0100, Paul Cager wrote:
> On Thu, May 3, 2007 12:14 am, Matthew Johnson wrote:
> >
> > It's a tricky one. A debhelper command in debian/rules is exactly where
> > it _ought_ to be.
>
> I agree; I'm just not sure how feasible it is to make it sufficiently
> robust for all cases.
>
> On the other hand quite a large proportion of Java packages are
> near-trivial, and could benefit from your idea. Maybe all you need to do
> is rename it as "dh_simplejavadeps" (for example), and let the packager
> decide if it is appropriate. Even with cdbs the maintainer would have to
> explicitly
> specify the use of ${java:Depends}.
I really like the idea. I just wonder how good it will work in the real
world.
> Would you want to attempt to derive "Build-Depends" from "Depends"?
Build-Depends is hard. You need to know them before you build anything.
We should avoid something like debian/control.in for trivial packages.
> > Does dh_shlibs not have similar problems which they've
> > fixed?
>
> dh_shlibs is a bit different. E.g. the compiled object contains the name
> and version of the *library* it requires.
The version of the library is not always included, but in general the
job of dh_shlibs is much easier.
> > Ideally
> > I'd write (not in bash) a real byte-code parser which can find the class
> > references properly.
>
> I would recommend "bcel" for this job (assuming you are coding in Java).
> It's nice and easy to use.
I would recommend ASM. Easier to use and even recommended by BCEL
developers for new projects. BCEL is more or less dead ... I mean in
maintenance mode. ASM even includes the dependency recognition as an
example.
We use ASM a lot at work. In my try to write such a tool like your
dh_javadeps I used it too.
Cheers,
Michael
--
.''`. | Michael Koch <konqueror@gmx.de>
: :' : | Free Java Developer <http://www.classpath.org>
`. `' |
`- | 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B
Reply to: