On Friday 16 September 2005 12:52, Andrew Haley wrote:
Vadim Nasardinov writes:
> On Friday 16 September 2005 07:24, Gary Benson wrote:
> > a brief summary:
> >
> > 1. Native code in the same rpms as the bytecode.
> > 2. Native code in separate rpms to the bytecode.
> ...
> > Method 2, which is what you're proposing, has the following
> > drawbacks over Method 1:
> ...
> > - The native package would not have access to the sources, and
> > would not be able to generate a useful debuginfo package.
> > This would render the packages undebuggable with gdb.
>
> Can you elaborate? I thought native compilation worked by taking
> .class files as input. Where do the sources come in?
You don't debug bytecode: you debug source. Debuginfo contains
source.
The part I didn't understand was how specifically Method 2 would
prevent you from generating appropriate debuginfo packages. I think
the source of my confusion was that I misintepreted Gary's definition
of "Method 2". I was thinking along the lines of David Walluck's
long-standing proposal (I hope I'm not putting words in his mouth) to
share exact same .spec files between Fedora and JPackage but have
native-compilation-related spec logic conditionalized.
I am a little fuzzy on why sharing exact same .spec files (modulo
minor distro-specific patches) is infeasible.
Even with Gary's definition of Method 2 (call it M2), it's not clear
to me why debuginfo packages are impossible to generate. (I think M2
amounts effectively to having two SRPMs for the same application).