Problem with my first app
PERON Stéphane
Hi all,
I'm trying to make a first app with GNUSTEP.
For help, I use the manual "First Steps in GNUSTEP Gui Programming"
from
Nicola Pero.
I have been trying to compile the Firstapp given as example :
#include <Fondation/Fondation.h>
#include <AppKit/AppKit.h>
@interface MyDelegate : NSObject
- (void) applicationWillFinishLaunching: (NSNotification *)not;
@end
@implementation MyDelegate
- (void) applicationWillFinishLaunching: (NSNotification *)not;
{
NSMenu *menu;
menu = AUTORELEASE ([NSMenu New]);
[menu addItemWithTitle: @"Quit"
action: @selector (terminate:)
keyEquivalent: @"q"];
[NSApp setMainMenu : menu];
}
@end
int main(int argc, const char **argv)
{
[NSApplication sharedApplication];
[NSApp setDelegate: [MyDelegate new]];
return NSApplicationMain (argc, argv);
}
When I compile, I have the following error message :
[stephane@boa Encod.app]$ make
Making all for app Encod...
gcc Encod.c -c -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -DGSWARN -O2 -fgnu-runtime -I. -I/opt/GNUstep/System/Headers -fgnu-runtime -I/opt/GNUstep/System/Headers -I/home/stephane/GNUstep/Library/Headers -I/opt/GNUstep/Local/Library/Headers -I/opt/GNUstep/Network/Library/Headers -I/opt/GNUstep/System/Library/Headers -I/opt/GNUstep/Network/Headers/gnustep -I/home/stephane/GNUstep/Headers/gnustep -I/opt/GNUstep/Local/Headers/gnustep -I/opt/GNUstep/System/Headers/gnustep -I/opt/GNUstep/Network/Headers/ix86/linux-gnu -I/home/stephane/GNUstep/Headers/ix86/linux-gnu -I/opt/GNUstep/Local/Headers/ix86/linux-gnu -I/opt/GNUstep/System/Headers/ix86/linux-gnu -I/home/stephane/GNUstep/Headers -I/opt/GNUstep/Local/Headers -I/opt/GNUstep/Network/Headers -I/opt/GNUstep/System/Headers -o shared_obj/ix86/linux-gnu/gnu-gnu-gnu/Encod.o
Encod.c:1:33: Fondation/Fondation.h: Aucun fichier ou répertoire de ce type
In file included from /opt/GNUstep/System/Headers/Foundation/Foundation.h:74,
from /opt/GNUstep/System/Headers/AppKit/AppKit.h:36,
from Encod.c:2:
/opt/GNUstep/System/Headers/Foundation/NSProtocolChecker.h:27:2: warning: #import is obsolete, use an #ifndef wrapper in the header file
make[2]: *** [shared_obj/ix86/linux-gnu/gnu-gnu-gnu/Encod.o] Erreur 1
make[1]: *** [Encod.build] Erreur 2
make: *** [Encod.all.app.variables] Erreur 2
So, do I have made a mistake ?
Thanks all
Bye
--
*****************
Stéphane PERON
spe...@telys.com
*****************
Jeff Teunissen
>
> Hi all,
>
> I'm trying to make a first app with GNUSTEP.
>
> For help, I use the manual "First Steps in GNUSTEP Gui Programming"
> from
> Nicola Pero.
>
> I have been trying to compile the Firstapp given as example :
>
> #include <Fondation/Fondation.h>
#include <Foundation/Foundation.h>
--
| Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net
| GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project http://www.quakeforge.net/
| Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
PERON Stéphane
say the include file "Fondation.h" does't not exist like it would have done in pure C ..well, I think so :) )
Well I have corrected the code which is below and I always meet a
problem at compilation :
#include <Foundation/Foundation.h>
#include <AppKit/AppKit.h>
@interface MyDelegate : NSObject
- (void) applicationWillFinishLaunching: (NSNotification *)not;
@end
@implementation MyDelegate : NSObject
- (void) applicationWillFinishLaunching: (NSNotification *)not
{
NSMenu *menu;
menu = AUTORELEASE ([NSMenu New]);
[menu addItemWithTitle: @"Quit"
action: @selector (terminate:)
keyEquivalent: @"q"];
[NSApp setMainMenu : menu];
}
@end
int main(int argc, const char **argv)
{
[NSApplication sharedApplication];
[NSApp setDelegate: [MyDelegate new]];
return NSApplicationMain (argc, argv);
}
Result at compilation :
/opt/GNUstep/System/Headers/AppKit/NSWorkspace.h:201: warning: data
definition has no type or storage class
Encod.c:4: parse error before `@'
Encod.c:12: conflicting types for `menu'
/opt/GNUstep/System/Headers/AppKit/NSMenu.h:198: previous declaration of
`menu'
Encod.c:12: parse error before `['
/opt/GNUstep/System/Headers/gnustep/base/o_map.h:89: storage size of
`extra_callbacks' isn't known
/opt/GNUstep/System/Headers/gnustep/base/o_hash.h:90: storage size of
`callbacks' isn't known
/opt/GNUstep/System/Headers/gnustep/base/o_map.h:92: storage size of
`key_callbacks' isn't known
/opt/GNUstep/System/Headers/gnustep/base/o_map.h:93: storage size of
`value_callbacks' isn't known
/opt/GNUstep/System/Headers/Foundation/NSThread.h:52: storage size of
`_autorelease_vars' isn't known
make[2]: *** [shared_obj/ix86/linux-gnu/gnu-gnu-gnu/Encod.o] Erreur 1
make[1]: *** [Encod.build] Erreur 2
make: *** [Encod.all.app.variables] Erreur 2
Well, not very clear for me :-) ............ Any Idea ?
Many thanks
--
Pierre-Yves Rivaille
using gcc 3.0.2. But :
> #include <Foundation/Foundation.h>
> #include <AppKit/AppKit.h>
>
> @interface MyDelegate : NSObject
> - (void) applicationWillFinishLaunching: (NSNotification *)not;
> @end
>
> @implementation MyDelegate : NSObject
should be
@implementation MyDelegate
because inheritance is only specified in the @interface part.
> - (void) applicationWillFinishLaunching: (NSNotification *)not
> {
> NSMenu *menu;
> menu = AUTORELEASE ([NSMenu New]);
should be
menu = AUTORELEASE ([NSMenu new]);
> [menu addItemWithTitle: @"Quit"
> action: @selector (terminate:)
> keyEquivalent: @"q"];
> [NSApp setMainMenu : menu];
> }
> @end
>
> int main(int argc, const char **argv)
> {
> [NSApplication sharedApplication];
> [NSApp setDelegate: [MyDelegate new]];
>
> return NSApplicationMain (argc, argv);
> }
Pierre-Yves
PERON Stéphane
I didn't know it was so hard to make a basic application :-)
With all changements, I always have problems at compilation :
/opt/GNUstep/System/Headers/AppKit/NSWorkspace.h:201: parse error
before `*'
/opt/GNUstep/System/Headers/AppKit/NSWorkspace.h:201: warning: data
definition has no type or storage class
Encod.c:4: parse error before `@'
You will find below my last code (in Encod.c) :
#include <Foundation/Foundation.h>
#include <AppKit/AppKit.h>
@interface MyDelegate : NSObject
- (void) applicationWillFinishLaunching: (NSNotification *)not;
@end
@implementation MyDelegate
- (void) applicationWillFinishLaunching: (NSNotification *)not
{
menu = AUTORELEASE ([NSMenu new]);
[menu addItemWithTitle: @"Quit"
action: @selector (terminate:)
keyEquivalent: @"q"];
[NSApp setMainMenu : menu];
}
@end
int main(int argc, const char **argv)
{
[NSApplication sharedApplication];
[NSApp setDelegate: [MyDelegate new]];
return NSApplicationMain (argc, argv);
}
Any new Idea ? :)
Thanks !
--
Nicola Pero
Hi,
> I have been trying to compile the Firstapp given as example :
>
> #include <Fondation/Fondation.h>
#include <Foundation/Foundation.h>
> Making all for app Encod...
> gcc Encod.c -c
the file should be called Encod.m - not Encod.c - otherwise gcc will try
to compile it as C source ... and obviously barf and spit on ObjC syntax.
:-)
Gregory Casamento
source file.
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep
=====
Gregory John Casamento
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
Philippe C.D. Robert
PERON Stéphane <spe...@telys.com> wrote:
> Ok, ok ... I have made a mistake (amaising that the compilator does not
> say the include file "Fondation.h" does't not exist like it would have done in pure C ..well, I think so :) )
>
> Well I have corrected the code which is below and I always meet a
> problem at compilation :
>
> #include <Foundation/Foundation.h>
> #include <AppKit/AppKit.h>
2 minor issues:
- AppKit.h already includes Foundation.h
- ObjC headers should be #imported, not #included
> @interface MyDelegate : NSObject
> - (void) applicationWillFinishLaunching: (NSNotification *)not;
> @end
>
> @implementation MyDelegate : NSObject
It's 'only'
@implementation MyDelegate
> - (void) applicationWillFinishLaunching: (NSNotification *)not
> {
> NSMenu *menu;
> menu = AUTORELEASE ([NSMenu New]);
Method names start with a lowercase character:
menu = AUTORELEASE ([NSMenu new]);
BTW the method 'new' does actually alloc/init using the designated initialiser - it is a 'deprecated' method (NeXT wanted to remove it switching from NS 2.x to 3.0, but at the end they did not because of legacy stuff ), so it is better to use alloc/init directly.
Hope this helps,
-Phil
--
Philippe C.D. Robert
Software Engineer
Silicon Graphics, Inc.
Richard Frith-Macdonald
On Sunday, October 14, 2001, at 04:05 PM, Philippe C.D. Robert wrote:
> On Sat, 13 Oct 2001 14:34:48 -0400
> PERON Stéphane <spe...@telys.com> wrote:
>
>> Ok, ok ... I have made a mistake (amaising that the compilator does not
>> say the include file "Fondation.h" does't not exist like it would have
>> done in pure C ..well, I think so :) )
>>
>> Well I have corrected the code which is below and I always meet a
>> problem at compilation :
>>
>> #include <Foundation/Foundation.h>
>> #include <AppKit/AppKit.h>
>
> 2 minor issues:
>
> - AppKit.h already includes Foundation.h
> - ObjC headers should be #imported, not #included
Actually the second point is a matter of taste ...
use of #import is in fact deprecated by the compiler.
The rationale I read for it being deprecated is that the
use of protective #ifndef and #defines in the headers is
preferred because it makes the way the header is meant to
be used explicit.
jclo...@home.com
MIME-Version: 1.0 (Generated by Pantomime 0.6.0)
Content-Type: text/plain
From: Jason Clouse <jclo...@home.com>
To: discuss...@gnu.org
Reply-To: jclo...@home.com
> - ObjC headers should be #imported, not #included
To change the subject, why is #import deprecated in gcc? It strikes me as odd to support a solution which: (1) breaks with established practice; (2) is--even if only mildly so--ugly; and (3) requires more typing :-). It seems to me that using #import gives you one less thing to remember to do.
J
Philippe C.D. Robert
Richard Frith-Macdonald <ric...@brainstorm.co.uk> wrote:
<snip>
> >> #include <Foundation/Foundation.h>
> >> #include <AppKit/AppKit.h>
> >
> > 2 minor issues:
> >
> > - AppKit.h already includes Foundation.h
> > - ObjC headers should be #imported, not #included
>
> Actually the second point is a matter of taste ...
> use of #import is in fact deprecated by the compiler.
> The rationale I read for it being deprecated is that the
> use of protective #ifndef and #defines in the headers is
> preferred because it makes the way the header is meant to
> be used explicit.
I did not knew that, but if this is true, then I consider that as a step backwards.
What are the reasons for this and who made decided upon that?
Philippe C.D. Robert
Jason Clouse <jclo...@home.com> wrote:
> > - ObjC headers should be #imported, not #included
>
> To change the subject, why is #import deprecated in gcc? It strikes me as odd to support a solution which: (1) breaks with established practice; (2) is--even if only mildly so--ugly; and (3) requires more typing :-). It seems to me that using #import gives you one less thing to remember to do.
I don't know - but I know that I dislike it *very much*. Your 3rd point is IMHO even a worse one because it is not only about typing but about having developers to type more ifdefs/defines, that is train them to use them all over the place, very ugly indeed!
BTW what says Apple to this, will they change to "#include" then as well (guessing that they will upgrade to gcc 3.x anytime in the midterm future as well)?
Nicola Pero
> menu = AUTORELEASE ([NSMenu new]);
>
> BTW the method 'new' does actually alloc/init using the designated
> initialiser - it is a 'deprecated' method
> (NeXT wanted to remove it switching from NS 2.x to 3.0,
> but at the end they did not because of legacy stuff ),
> so it is better to use alloc/init directly.
new is not at all deprecated and is in widespread use.
if you don't like it, that's another matter, and we can discuss about it
(I could even agree with you), but please give newcomers a fair and
neutral description of the state of things ... it's perfectly good and
normal and standard to use +new (and similar methods) in Objective-C code.
Philippe C.D. Robert
That is exactly what I am doing...;-)
'new' - as I mentioned - is only in the OpenStep (and late NS 3.x ) API because of legacy support. But this is not enough reasoning in that case, I agree. I also explained what 'new' does in a 'fair and neutral way' - and here begin the problems:
- you do not know what new exactly does by looking at the name
- it is not exactly the same as in C++ thus misleading to newcomers coming from that part of the world
- engineering wise, alloc/init is much more beautiful because it separates allocation and initialisation. If you ever did C++ coding you know why this is a plus!
- The docu is ambiguous: "Allocates a new instance of the receiving class, sends it an init message, and returns the initialized object." Does this mean it always calls init or do subclasses correctly call the super class' designated initialiser? The docu says "sometimes"... For existing classes this is not a real problem but what is expected from your subclasses...?
- Subclassing is a problem, because 'new' sometimes does not only alloc/init but also other things ( see the NSObject docu )...
But I have to agree that it is not deprecated in the common sense (it is still part of the API), I should have made the clearer in my first email. I guess it belongs into the same category as the RELEASE/AUTORELEASE/... macros, but that is another story...
Nicola Pero
> > > - ObjC headers should be #included, not #imported
> > - ObjC headers should be #imported, not #included
>
> less than 13 lines ! when using #import. What kind of backward
> discrimination is it to force us Objective-C programmers to add a
> -Wno-import option to each compile to avoid it.
Hmm ... well, it's clearly a religious/matter of taste problem.
(just to clear up my coscience, I will confess that I personally prefer
#include over #import)
I think the environment should be neutral to this kind of matters,
allowing people of both sides to code happily ... yes I agree that
probably gcc should not take parts either so it should not emit warnings
for #import ... but it's not a big problem because in gnustep-make we
always and automatically add the -Wno-import flag to the compilation
flags, so if you use #import, you should be absolutely fine and never see
any warnings from gcc.
Stan Shebs
>
> On Sun, 14 Oct 2001 13:58:25 -0400
> Jason Clouse <jclo...@home.com> wrote:
>
> > > - ObjC headers should be #imported, not #included
> >
> > To change the subject, why is #import deprecated in gcc? It strikes me as odd to support a solution which: (1) breaks with established practice; (2) is--even if only mildly so--ugly; and (3) requires more typing :-). It seems to me that using #import gives you one less thing to remember to do.
>
> I don't know - but I know that I dislike it *very much*. Your 3rd point is IMHO even a worse one because it is not only about typing but about having developers to type more ifdefs/defines, that is train them to use them all over the place, very ugly indeed!
#import is not well-defined, and hard, perhaps even impossible, to
get right for all OSes and and all filesystems. The problem is that
it requires a notion of file identity, so it can know to avoid
including the "same" file more than once. But how do you detect
"same" file? By name? No, because of symlink tricks. By inode?
Better, but not every filesystem has inodes, and other filesystems
have inodes that are dynamically assigned as for instance NFS
mounts and unmounts things. This is not hypothetical, Apple has
experienced some mysterious include bugs caused by these kinds of
effects. By md5? Can't check it without reading the whole file,
not good for performance. Yes, the md5 could be stored in the
filesystem, but then we're back to the portability problem.
The #ifndef/#define strategy requires the programmer to establish
a single global space of #defines. It can still fail, for instance
when mixing packages that have similarly-named include files, but
at least everything is explicit and well-defined.
> BTW what says Apple to this, will they change to "#include" then as well (guessing that they will upgrade to gcc 3.x anytime in the midterm future as well)?
No, we'll continue to use #import, and turn off the warning too in
Apple's version of GCC. And yes, 3.x is in the works, I'm personally
in C++ hell right now (ObjC "just works", while C++ is a huge pain).
Stan