RE: [java-gnome-hackers] Makefile change?

[Tom B. <Tom...@Su...>]

It seems I only have read access to the CVS repository.  The
src/Makefile.in changes are ready; I also fixed the javadoc generation
target.  

Regarding javadoc, would anyone mind if I got rid of the empty javadoc
directory from the CVS tree by moving it into a .Attic directory?  It
would make cleaning the javadoc target much easier if that directory
were created by the build, as it could then just be completely deleted.

Tom

On Mon, 2002-10-21 at 05:13, Jeffrey Morgan wrote:
> > I started investigating the libglade port by building what's already
> > there, and found a surprise:  on Linux (probably Solaris too, but it's
> > been awhile) the default linker mode is to allow unresolved external
> > references during a build.  In this case, 
> > org_gnu_glade_LibGlade.c calls
> > makeBaseObjectClass which I can't find anywhere.  Is that 
> > unimplemented,
> > or am I missing a library?
> 
> That is an old method that is no longer around.  It's purpose
> was to make a java object and initialize the pointer to the
> native peer.  Below is the source for this method.
> 
> jobject makeBaseObjectClass (JNIEnv *env, void *peer)
> {
>   if (peer == NULL) {
>     return NULL;
>   }
>   else {
>     jclass cls;
>     jobject result;
>     jlong result_jl;
>     char class[20];
>     char fullclass[100];
>     int cmp;
> 
>     strcpy(class, gtk_type_name(GTK_OBJECT_TYPE(peer)));
>     cmp = strncmp("Gtk", class, 3);
>     if (cmp == 0)
>       sprintf(fullclass, "gnu/gtk/%s", class);
>     else
>       sprintf(fullclass, "gnu/gnome/%s", class);
>     
>     cls = (*env)->FindClass(env, fullclass);
>     
>     result = (*env)->AllocObject(env, cls);
>     *(void **) &result_jl = peer;
>     (*env)->SetLongField (env, result, nativepeerFid, result_jl);
>     return result;
>   }
> }
> 
> As you can see, much of this code is not relevant to the
> current state of the project.
> 
> > But back to the build problem: IMHO the build should have 
> > failed because
> > makeBaseObjectClass was missing, instead of failing at run 
> > time.  Adding
> > "-Xlinker --no-undefined" to each link step catch the error during the
> > build.  I replaced the makeBaseObjectClass call temporarily 
> > with a "not
> > implemented" exception throw -- the method still isn't 
> > implemented, but
> > at least the error says it's because a method was called 
> > which shouldn't
> > have been (yet), and not because of a problem in the client 
> > environment.
> > 
> > Since this is both my first proposed change and one that changes the
> > current build philosophy, I thought I should run it by 
> > everyone first. 
> > Anyone feel strongly that we shouldn't check for unresolved references
> > during the build?
> 
> I think it is time we clean up the build process.  I completely
> agree with your suggestion.
> 
> -Jeff