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] |
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] |