Re: PATCH: suppress deprecation warnings on OS X Leopard
On 30 Mar 2008, at 14:55, Blake Nicholson wrote: Nicola, Unfortunately, I think the sample output I sent was not a good representation. Sorry about that. I went ahead and built base under apple-apple-apple and redirected stderr to a file. I've attached the file so you can see all the error messages (many, many duplicates). Most of the error messages are from things in objc- gnu2next.h and GSObjCRuntime.h. Thanks ... OK, so we need to add the -Wno-deprecated everywhere in apple-gnu-gnu (and presumably, if you're compiling the gnustep-base Additions, also on apple-apple-apple). The right fix still seems to be to update the Apple runtime code in gnustep-base to work with the new runtime if available, but in the meanwhile if we add the -Wno-deprecated flag, we should probably add it inside gnustep-base so that when support for the new runtime is available, we can remove it in sync. :-) So I think that the right approach is: * have core/base/configure.ac detect that we're using the new Apple runtime [this test will be good in the future as well for when we actually add support for the new runtime ;-)] * in that case, have core/base/configure.ac add -Wno-deprecated to some autoconf output variable (eg, let's call it WNO_DEPRECATED_OBJCFLAGS), else leave it empty * have base.make.in set AUXILIARY_OBJFLAGS += @WNO_DEPRECATED_OBJCFLAGS@ when running with the Apple runtime Does that make any sense to you ? Thanks for your help ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PATCH: suppress deprecation warnings on OS X Leopard
On Mar 30, 2008, at 10:27 AM, Nicola Pero wrote: On 30 Mar 2008, at 14:55, Blake Nicholson wrote: Nicola, Unfortunately, I think the sample output I sent was not a good representation. Sorry about that. I went ahead and built base under apple-apple-apple and redirected stderr to a file. I've attached the file so you can see all the error messages (many, many duplicates). Most of the error messages are from things in objc- gnu2next.h and GSObjCRuntime.h. Thanks ... OK, so we need to add the -Wno-deprecated everywhere in apple-gnu-gnu (and presumably, if you're compiling the gnustep-base Additions, also on apple-apple-apple). The right fix still seems to be to update the Apple runtime code in gnustep-base to work with the new runtime if available, but in the meanwhile if we add the -Wno-deprecated flag, we should probably add it inside gnustep-base so that when support for the new runtime is available, we can remove it in sync. :-) Agreed. Please note that the option to set is -Wno-deprecated- declarations, not -Wno-deprecated. The latter is specific to C++. So I think that the right approach is: * have core/base/configure.ac detect that we're using the new Apple runtime [this test will be good in the future as well for when we actually add support for the new runtime ;-)] * in that case, have core/base/configure.ac add -Wno-deprecated to some autoconf output variable (eg, let's call it WNO_DEPRECATED_OBJCFLAGS), else leave it empty * have base.make.in set AUXILIARY_OBJFLAGS += @WNO_DEPRECATED_OBJCFLAGS@ when running with the Apple runtime Does that make any sense to you ? Thanks for your help The one question I have for you is will base.make be included when compiling something else, such as GDL2? Since other projects include GSCategories.h, which includes GSObjCRuntime.h and preface.h, AUXILIARY_OBJCFLAGS needs to be set for GNUstep projects besides base as well. BTW, it appears that clean_os.sh is a bit out of date (it only goes up through darwin7). Here's a patch that won't require each version of darwin to be listed separately. When the os is like darwin*, it strips everything from the first '.' on. This does introduce a dependency on sed, but my assumption is that any platform that has sh and can run this script will have sed. Do you agree? Index: clean_os.sh === --- clean_os.sh (revision 26396) +++ clean_os.sh (working copy) @@ -32,18 +32,10 @@ exit 0 ;; # Remove version number for Darwin -darwin7*) -echo darwin7 +darwin*) +echo `echo $1 | sed s/..*//` exit 0 ;; -darwin6*) -echo darwin6 -exit 0 -;; -darwin5*) -echo darwin5 -exit 0 -;; *) echo $1 exit 0 Thanks, Blake ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PATCH: suppress deprecation warnings on OS X Leopard
On Mar 30, 2008, at 9:27 AM, Nicola Pero wrote: The right fix still seems to be to update the Apple runtime code in gnustep-base to work with the new runtime if available, but in the meanwhile if we add the -Wno-deprecated flag, we should probably add it inside gnustep-base so that when support for the new runtime is available, we can remove it in sync. :-) It's been a few months, so I'm starting to forget everything, but IIRC, I did a small bit of work in this area when creating the GNUstepWeb packages for Mac OS X: http://hoth.radiofreeomaha.net:3000/~tmcintos/GNUstepWeb/ I believe I was also trying to reorganize some code to eliminate the need to include GSObjCRuntime.h in GSCategories.h and minimize the inclusion of GSObjCRuntime.h in general outside of -base. I was planning to go back and sort all of this out when I found some time-- reviewing everything, eliminating unnecessary changes, and breaking the remaining changes down into smaller patches that I could submit for consideration--but I haven't gotten around to that yet. GNUstep seems to do a lot of mucking with the runtime structures that are no longer visible with Obj-C 2.0, so I think the changes I made were just barely scratching the surface in view of what is actually needed. Not being familiar enough with the GNUstep code base, I have to wonder if all of the direct use of the runtime APIs is really needed; I can see where it would be necessary on occasion within - base, but I was surprised by the number of times I saw it being used in higher-level frameworks. -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PATCH: suppress deprecation warnings on OS X Leopard
The right fix still seems to be to update the Apple runtime code in gnustep-base to work with the new runtime if available, but in the meanwhile if we add the -Wno-deprecated flag, we should probably add it inside gnustep-base so that when support for the new runtime is available, we can remove it in sync. :-) Agreed. Please note that the option to set is -Wno-deprecated- declarations, not -Wno-deprecated. The latter is specific to C++. OK - thanks :-) The one question I have for you is will base.make be included when compiling something else, such as GDL2? Yes :-) BTW, it appears that clean_os.sh is a bit out of date (it only goes up through darwin7). Here's a patch that won't require each version of darwin to be listed separately. When the os is like darwin*, it strips everything from the first '.' on. This does introduce a dependency on sed, but my assumption is that any platform that has sh and can run this script will have sed. Do you agree? Yes, I agree that we can assume that sed is available ... It's an excellent patch, and I applied it. :-) Thanks PS: I made a tiny change to the patch due to my performance paranoia - won't make (almost) any difference. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PATCH: suppress deprecation warnings on OS X Leopard
On Mar 30, 2008, at 5:31 PM, David Ayers wrote: Tim McIntosh schrieb: GNUstep seems to do a lot of mucking with the runtime structures that are no longer visible with Obj-C 2.0, so I think the changes I made were just barely scratching the surface in view of what is actually needed. Not being familiar enough with the GNUstep code base, I have to wonder if all of the direct use of the runtime APIs is really needed; I can see where it would be necessary on occasion within -base, but I was surprised by the number of times I saw it being used in higher-level frameworks. Indeed we heavily rely on that mucking in GDL2. But let me state this clearly... we are not mucking in the runtime for performance reasons... we are just trying to get WO45 compatibility. So if anyone has better ideas on how we can solve these issues with the public API of Foundation, I'm up for it! Thanks for the info and clarification. I didn't mean to pick on GDL2 here; I had just gotten the impression from experimenting with various things that the runtime API is used in a number of places outside of -base, and sometimes it was not clear why. I think part of this impression may have come from GSObjCRuntime.h getting pulled in by GSCategories.h in cases where it is not necessarily needed. This is why I was attempting to eliminate that #include. In any case, it looked to me like there may be a lot of work to do wrt supporting the GSObjCRuntime.h interface on the Apple's Obj-C 2.0 runtime (which is probably really only needed to support 64-bit; I can't see them removing the old APIs in the 32-bit version any time soon). Regards, Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PATCH: suppress deprecation warnings on OS X Leopard
Maybe we could add the flag only when compiling GSObjCRuntime.m ?
After all, that file is the only file
which should access the runtime internals directly ? :-)
Something like the following (added to the GNUmakefile) should do it
ifneq ($(OBJC_RUNTIME_LIB), gnu)
GSObjCRuntime.m_FILE_FLAGS = -Wno-deprecated-declarations
endif
Does it work for you ?
Of course, it would also be worth updating GSObjCRuntime.m so that it
works with the new Apple runtime stuff. ;-)
Thanks
On 24 Mar 2008, at 14:13, Blake Nicholson wrote:
Nicola,
Thanks for your reply. I've pasted in a small snippet of the make
output below. These are deprecation warnings related to ObjC 2.0.
The vast majority of the deprecated items are in runtime.h, but
there are a few other declarations in other headers that are
deprecated as well. The items are marked with the macro
OBJC2_UNAVAILABLE, which has the underlying definition of
__attribute__((deprecated)).
An alternative is to execute make as 'make OBJCFLAGS=-Wno-
deprecated-declarations', but my hope was that this could be
incorporated into target.make since I can't think of a reason
someone would want these warnings enabled.
Below the make output snippet, I pasted in the corresponding
snippet of runtime.h that generates these warnings. I hope this is
enough information to be helpful, but let me know if you need
something else.
Thanks,
Blake
*** snippet of make output ***
GSObjCRuntime.m:448: warning: ‘objc_class’ is deprecated (declared
at built-in:0)
GSObjCRuntime.m:449: warning: ‘objc_class’ is deprecated (declared
at built-in:0)
GSObjCRuntime.m:451: warning: ‘super_class’ is deprecated (declared
at /usr/include/objc/runtime.h:47)
GSObjCRuntime.m:452: warning: ‘name’ is deprecated (declared at /
usr/include/objc/runtime.h:48)
GSObjCRuntime.m:453: warning: ‘version’ is deprecated (declared at /
usr/include/objc/runtime.h:49)
GSObjCRuntime.m:454: warning: ‘info’ is deprecated (declared at /
usr/include/objc/runtime.h:50)
GSObjCRuntime.m:457: warning: ‘instance_size’ is deprecated
(declared at /usr/include/objc/runtime.h:51)
GSObjCRuntime.m:461: warning: ‘objc_ivar’ is deprecated (declared
at /usr/include/objc/runtime.h:39)
GSObjCRuntime.m:468: warning: ‘objc_ivar_list’ is deprecated
(declared at /usr/include/objc/runtime.h:52)
*** snippet of runtime.h header definition that causes the warnings
***
struct objc_class {
Class isa;
#if !__OBJC2__
Class super_class
OBJC2_UNAVAILABLE;
const char *name
OBJC2_UNAVAILABLE;
long version
OBJC2_UNAVAILABLE;
long info
OBJC2_UNAVAILABLE;
long instance_size
OBJC2_UNAVAILABLE;
struct objc_ivar_list *ivars
OBJC2_UNAVAILABLE;
struct objc_method_list **methodLists
OBJC2_UNAVAILABLE;
struct objc_cache *cache
OBJC2_UNAVAILABLE;
struct objc_protocol_list *protocols
OBJC2_UNAVAILABLE;
#endif
} OBJC2_UNAVAILABLE;
/* Use `Class` instead of `struct objc_class *` */
On Mar 24, 2008, at 7:47 AM, Nicola Pero wrote:
Hi Blake
Sorry for not answering before - I don't have Leopard, so I don't
really know what warnings you are trying to suppress. ;-)
Can you send us the output of 'make messages=yes' on Mac OS X that
shows the warnings you are wanting to suppress ?
Thanks
On 22 Mar 2008, at 14:45, Blake Nicholson wrote:
I sent this a few days back and haven't heard anything so I
thought I'd try again. I'm not sure if I haven't heard anything
because few people are running Leopard, this isn't a patch people
think should be applied, or if everyone is simply busy with other
things.
Whatever the case may be, if anyone can spare a few minutes to
consider this patch, I'd appreciate it. Two specific questions I
have are:
1) Is target.make an okay place to put this or should individual
GNUstep sub-projects make their own decision on whether to add
this to their relevant makefiles?
2) Is INTERNAL_OBJCFLAGS the correct variable to which this
compiler setting should be added?
Thanks,
Blake
Begin forwarded message:
From: Blake Nicholson [EMAIL PROTECTED]
Date: March 18, 2008 4:00:28 PM GMT-04:00
To: gnustep-dev@gnu.org
Subject: PATCH: suppress deprecation warnings on OS X Leopard
The following patch modifies target.make so that it adds the
compiler option -Wno-deprecated-declarations when compiling
GNUstep on Mac OS X 10.5 (Leopard) using Apple's GCC. Is this
kind of wholesale disabling of warnings okay, or should this be
done on an individual GNUmakefile level?
Thanks,
Blake
Index: target.make
===
--- target.make (revision 26339)
+++
Re: PATCH: suppress deprecation warnings on OS X Leopard
Nicola,
Thanks for your reply. I've pasted in a small snippet of the make
output below. These are deprecation warnings related to ObjC 2.0.
The vast majority of the deprecated items are in runtime.h, but there
are a few other declarations in other headers that are deprecated as
well. The items are marked with the macro OBJC2_UNAVAILABLE, which
has the underlying definition of __attribute__((deprecated)).
An alternative is to execute make as 'make OBJCFLAGS=-Wno-deprecated-
declarations', but my hope was that this could be incorporated into
target.make since I can't think of a reason someone would want these
warnings enabled.
Below the make output snippet, I pasted in the corresponding snippet
of runtime.h that generates these warnings. I hope this is enough
information to be helpful, but let me know if you need something else.
Thanks,
Blake
*** snippet of make output ***
GSObjCRuntime.m:448: warning: ‘objc_class’ is deprecated (declared at
built-in:0)
GSObjCRuntime.m:449: warning: ‘objc_class’ is deprecated (declared at
built-in:0)
GSObjCRuntime.m:451: warning: ‘super_class’ is deprecated (declared
at /usr/include/objc/runtime.h:47)
GSObjCRuntime.m:452: warning: ‘name’ is deprecated (declared at /usr/
include/objc/runtime.h:48)
GSObjCRuntime.m:453: warning: ‘version’ is deprecated (declared at /
usr/include/objc/runtime.h:49)
GSObjCRuntime.m:454: warning: ‘info’ is deprecated (declared at /usr/
include/objc/runtime.h:50)
GSObjCRuntime.m:457: warning: ‘instance_size’ is deprecated (declared
at /usr/include/objc/runtime.h:51)
GSObjCRuntime.m:461: warning: ‘objc_ivar’ is deprecated (declared at /
usr/include/objc/runtime.h:39)
GSObjCRuntime.m:468: warning: ‘objc_ivar_list’ is deprecated (declared
at /usr/include/objc/runtime.h:52)
*** snippet of runtime.h header definition that causes the warnings ***
struct objc_class {
Class isa;
#if !__OBJC2__
Class super_class
OBJC2_UNAVAILABLE;
const char *name
OBJC2_UNAVAILABLE;
long version
OBJC2_UNAVAILABLE;
long info
OBJC2_UNAVAILABLE;
long instance_size
OBJC2_UNAVAILABLE;
struct objc_ivar_list *ivars
OBJC2_UNAVAILABLE;
struct objc_method_list **methodLists
OBJC2_UNAVAILABLE;
struct objc_cache *cache
OBJC2_UNAVAILABLE;
struct objc_protocol_list *protocols
OBJC2_UNAVAILABLE;
#endif
} OBJC2_UNAVAILABLE;
/* Use `Class` instead of `struct objc_class *` */
On Mar 24, 2008, at 7:47 AM, Nicola Pero wrote:
Hi Blake
Sorry for not answering before - I don't have Leopard, so I don't
really know what warnings you are trying to suppress. ;-)
Can you send us the output of 'make messages=yes' on Mac OS X that
shows the warnings you are wanting to suppress ?
Thanks
On 22 Mar 2008, at 14:45, Blake Nicholson wrote:
I sent this a few days back and haven't heard anything so I thought
I'd try again. I'm not sure if I haven't heard anything because
few people are running Leopard, this isn't a patch people think
should be applied, or if everyone is simply busy with other things.
Whatever the case may be, if anyone can spare a few minutes to
consider this patch, I'd appreciate it. Two specific questions I
have are:
1) Is target.make an okay place to put this or should individual
GNUstep sub-projects make their own decision on whether to add this
to their relevant makefiles?
2) Is INTERNAL_OBJCFLAGS the correct variable to which this
compiler setting should be added?
Thanks,
Blake
Begin forwarded message:
From: Blake Nicholson [EMAIL PROTECTED]
Date: March 18, 2008 4:00:28 PM GMT-04:00
To: gnustep-dev@gnu.org
Subject: PATCH: suppress deprecation warnings on OS X Leopard
The following patch modifies target.make so that it adds the
compiler option -Wno-deprecated-declarations when compiling
GNUstep on Mac OS X 10.5 (Leopard) using Apple's GCC. Is this
kind of wholesale disabling of warnings okay, or should this be
done on an individual GNUmakefile level?
Thanks,
Blake
Index: target.make
===
--- target.make (revision 26339)
+++ target.make (working copy)
@@ -343,6 +343,10 @@
ifeq ($(findstring darwin7, $(GNUSTEP_TARGET_OS)), darwin7)
DYLIB_EXTRA_FLAGS+= -Wl,-single_module
endif
+# suppress deprecation warnings on OS X 10.5 (Leopard)
+ifeq ($(findstring darwin9, $(GNUSTEP_TARGET_OS)), darwin9)
+ INTERNAL_OBJCFLAGS += -Wno-deprecated-declarations
+endif
SHARED_LIB_LINK_CMD = \
$(CC) $(SHARED_LD_PREFLAGS) \
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
