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

[Jeffrey M. <ku...@zo...>]

Have you made progress on the makefile changes?

On Sat, 2002-10-26 at 14:49, Tom Ball wrote:
> 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
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ApacheCon, November 18-21 in
> Las Vegas (supported by COMDEX), the only Apache event to be
> fully supported by the ASF. http://www.apachecon.com
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>