This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: Patch: Remove fastjar


Hi Per,

On Thu, 2006-03-30 at 16:29 -0800, Per Bothner wrote:
> Mark Wielaard wrote:
> > On Thu, 2006-03-30 at 18:29 -0500, Andrew Pinski wrote:
> >>> Perhaps gcc/doc/install.texi should have something added to reflect the 
> >>> new requirements for building.
> >> I still say there is a misunderstanding going on because not all
> >> people will already have a jar program installed (in fact I don't
> >> one installed on my work GNU/Linux box).  Making a new requirment
> >> to compile libgcj will make GCC people think twice about compiling
> >> GCC.
> > 
> > It is going to be a bit of extra pain for users to compile libgcj if
> > this is removed from the tree. Would it be possible to use the minizip
> > implementation from the included zlib to create the jar/zip file? That
> > way we don't introduce an extra dependency on the user. Or try to detect
> > a working zip binary on the users system? At least a zip utility is more
> > likely to be available then a jar utility.
> 
> Ideally, I'd like to get rid of fastjar.  It should be replaced by a
> wrapper on top of java.util.zip and java.util.jar.  I assume this is
> what Sun does.  Is there any reason to not do that?

Theoretically not. It would make bootstrapping things a bit more
interesting. But as you said those things can be done with some careful
thought about what gets build when/where and depends on what. The real
reason we don't have such a gjar wrapper based on the libgcj/classpath
util.jar package itself is that there was no practical need because we
already have fastjar. Raif wrote a jarsigner tool for GNU Classpath just
recently, that could be a base for such a gjar tool. But I am not really
convinced that ripping out fastjar to force someone to write such a
replacement to include in the gcc source tree is a very productive. On
the other hand it is probably just a couple of days of work, so if that
really makes everybody happy and gets us forward again then please go
for it!

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part


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