java-gnome-hackers

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

[Jeffrey M. <Jef...@Br...>]

> 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

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

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
> 

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

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

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.  

I just checked and you do have full cvs access.  Make sure you are
using ssh by setting CVS_RSH=ssh.

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

This is fine with me.

-Jeff

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

[Philip A. C. <pc...@td...>]

On Fri, 2002-10-25 at 23:03, Jeffrey Morgan wrote:
> 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. =20
>=20
> I just checked and you do have full cvs access.  Make sure you are
> using ssh by setting CVS_RSH=3Dssh.

Also, make sure you are not editing source checked out anonymously
before you became a member of the project.  Even if you give CVS the
right login info, it seems to defer to what it finds in CVS/Root.  I
made this mistake when I first got started.

--=20
Philip A. Chapman

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

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

On Fri, 2002-10-25 at 21:03, Jeffrey Morgan wrote:
> 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.  
> 
> I just checked and you do have full cvs access.  Make sure you are
> using ssh by setting CVS_RSH=ssh.

Ah, that's the problem -- NetBeans CVS repository doesn't require SSH. 
Thanks!

Tom

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

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

Sorry this took so long (it's checked in now).  My only excuse is that
being in the middle of a layoff takes its toll, even if one isn't a
target.

Tom

On Mon, 2002-10-28 at 21:31, Jeffrey Morgan wrote:
> 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
> > 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers