Tom Tromey wrote:
>>>>>> "Tom" == Thomas Fitzsimmons <fitzsim@xxxxxxxxxx> writes:
>
>>> Anyway, I think that classpath should be buildable without any
>>> mozilla dependencies.
>
> Tom> Try --disable-plugin.
>
> For eclipse-based builds it would be friendlier if, by default,
> configure would search for the needed libraries and then simply not
> compile things if dependencies are missing.
I considered this approach. I'd rather it be clear that certain
features of GNU Classpath are disabled if one does not have the proper
dependencies installed. An alternative to configure failing outright
that I've seen in other projects is printing out a long list of:
feature x: enabled
feature y: disabled
lines at the end of the configure run. Even then though, it's not clear
to a person wanting to build the plugin (which should be the majority of
GNU Classpath developers) why it is disabled. The current configure
failure makes it very clear that he needs the Mozilla development
libraries to have a full-featured GNU Classpath build.
>
> Also I noticed we are doing this:
>
> AC_SUBST(PLUGIN_DIR, $HOME/.mozilla/plugins/)
>
> That seems weird, especially for distro use. (Also according to GNU
> standards we shouldn't install anything outside $prefix.) I think we
> probably need another option to set this install directory.
>
> Finally... I see this in the plugin Makefile.am:
>
> install-libLTLIBRARIES: $(lib_LTLIBRARIES)
> $(INSTALL) -d -m0755 $(DESTDIR)@PLUGIN_DIR@
> $(INSTALL) .libs/libgcjwebplugin.so $(DESTDIR)@PLUGIN_DIR@
>
> Overriding an internal rule is not supported by automake. If we
> really, really want to do this, then the correct approach is a new
> directory variable.
Yes, these are a little weird. I copied them directly from
gcjwebplugin. I like this as the default behaviour because it means
that make && make install actually installs the plugin in a useable way.
What about a --with-plugin-directory option that defaults to
$HOME/.mozilla/plugins? Then packagers could override this with
/usr/lib/mozilla/plugins.
Tom
