RE: Problem building gnustep-base tools with MinGW
Selon Nicola Pero <[EMAIL PROTECTED]>:
>
> >> ./configure --with-layout=fhs
> >> make
> >> make install
> >
> >Done.
> >Does not work : same errors.
> >
>
> That's surprising. :-(
>
> It seems to suggest that probably the problem is something else. :-/
> Maybe it's a bug in gnustep-base then ?
>
> It looks like I'll have to reboot under Microsoft Windows and try it all
> again. :-/
>
>
>
> >> PS: stuff like
> >>
> >> ./configure --prefix=C:/GNUstep
> >>
> >> is no longer recommended and might not work. To make things simpler, we
> >> prefer people to develop in the clean MSYS/MinGW Unix-like environment
> >> where it's guaranteed that there are *no* problems, but making sure the
> >> resulting binaries can be then shipped/distributed/organized
> >> in some other, more Windows-friendly, way. ;-)
> >
> > So GNUstep becomes an Unix-like environment. That's bad.
> >
>
> Well ... GNUstep command-line development is Unix-like, but it has
> always been like that. Things are compiled using sh/make/gcc ...
> that's why you need MSYS. ;-)
MSYS is only a developper tool, a command prompt with bash, and
is not mandatory : you can use any mingw tools from a Windows
prompt. A command you type in a MSYS box only use mingw; if you pass a
'path' as an argument to a command, MSYS bash translates it to a Window path.
Just try this at MSYS prompt : (dont type the '$' ;o)
$cat > test.c
#include
main( int argc, char**argv) { puts(argv[1]); }
^D
$gcc test.c
$a /usr/local
I get :
c:/Dev/MinGW/local
> If you mix Unix paths with non-Unix paths sh/make/gcc/etc get easily
> confused.
A MinGW command never use MSYS tree.
MinGw doesnt know /usr/local/GNUstep, it knows c:/MSYS/1.0/local/GNUstep
So unix paths and non-unix paths are never mixed.
Should i say 'always' ? hum... ;o)
Problems happen with space char in file name, or with backslash
> Then things maybe work, maybe not, and it's difficult to get things working
> consistently, predictably and reliably. Which is why we really recommend
> working inside MSYS when building, other types of building are not really
> supported.
That what i do :-)
> But once you have built your stuff, you are free to use your environment
> in a more Windows-like setup! :-)
>
> > Even my MSYS/mingw installation is not 'standard' as i use some
> > msys-links :
> > / is C:\Dev\msys\1.0
> > /mingw is C:\Dev\MinGW\mingw
> > /usr/local is C:\Dev\MinGW\local
> > Should that work with GNUstep or do I have to reinstall the
> > whole thing ?
>
> I'm not sure, I'd need to boot Windows to help you here. :-/
>
> But if you can figure out how to use these 'links' then I imagine that
> you can put GNUstep wherever you want on disk ;-)
>
> Just create a "link"
>
> /usr/GNUstep --> C:\GNUstep
MSYS links may be defined in /etc/fstab
But that not mandatory : for MSYS, C:\GNUstep is always /c/GNUstep
If i type :
$make --prefix=/c/GNUstep
make gets : --prefix=c:/GNUstep
(try with the little program above)
When you build anything you can see the paths that are used by gcc.
All of them start with 'c:/'
regards
Xavier
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Problem building gnustep-base tools with MinGW
>> ./configure --with-layout=fhs >> make >> make install > >Done. >Does not work : same errors. > That's surprising. :-( It seems to suggest that probably the problem is something else. :-/ Maybe it's a bug in gnustep-base then ? It looks like I'll have to reboot under Microsoft Windows and try it all again. :-/ >> PS: stuff like >> >> ./configure --prefix=C:/GNUstep >> >> is no longer recommended and might not work. To make things simpler, we >> prefer people to develop in the clean MSYS/MinGW Unix-like environment >> where it's guaranteed that there are *no* problems, but making sure the >> resulting binaries can be then shipped/distributed/organized >> in some other, more Windows-friendly, way. ;-) > > So GNUstep becomes an Unix-like environment. That's bad. > Well ... GNUstep command-line development is Unix-like, but it has always been like that. Things are compiled using sh/make/gcc ... that's why you need MSYS. ;-) If you mix Unix paths with non-Unix paths sh/make/gcc/etc get easily confused. Then things maybe work, maybe not, and it's difficult to get things working consistently, predictably and reliably. Which is why we really recommend working inside MSYS when building, other types of building are not really supported. But once you have built your stuff, you are free to use your environment in a more Windows-like setup! :-) > Even my MSYS/mingw installation is not 'standard' as i use some > msys-links : > / is C:\Dev\msys\1.0 > /mingw is C:\Dev\MinGW\mingw > /usr/local is C:\Dev\MinGW\local > Should that work with GNUstep or do I have to reinstall the > whole thing ? I'm not sure, I'd need to boot Windows to help you here. :-/ But if you can figure out how to use these 'links' then I imagine that you can put GNUstep wherever you want on disk ;-) Just create a "link" /usr/GNUstep --> C:\GNUstep then if gnustep-make can access the stuff from the shell as /usr/GNUstep, everything should work fine ... and you can still find GNUstep on your harddisk in C:\GNUstep. :-) Presumably if all is about finding GNUstep on your harddisk you can also create a desktop link (reference ? whatever it was called under MS Windows) pointing to /usr/GNUstep. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Problem building gnustep-base tools with MinGW
Selon Nicola Pero <[EMAIL PROTECTED]>: > >> I suggest following the instructions on > core/make/Documentation/README.MinGW. > > > > That's what i did. Many times :-(( > > > > Which version of the document are you following ? > > You should follow the one that comes with the version of > gnustep-make that you are using. In particular, the one > from trunk suggests configuring gnustep-make as: Yes : suggests. Has i am a free man i choose anything else :-) > ./configure --with-layout=fhs > make > make install Done. Does not work : same errors. > PS: stuff like > > ./configure --prefix=C:/GNUstep > > is no longer recommended and might not work. To make things simpler, we > prefer people to develop in the clean MSYS/MinGW Unix-like environment > where it's guaranteed that there are *no* problems, but making sure the > resulting binaries can be then shipped/distributed/organized > in some other, more Windows-friendly, way. ;-) So GNUstep becomes an Unix-like environment. That's bad. Do you mean i also have to put my /home directory and my source files where you think they should be ? Even my MSYS/mingw installation is not 'standard' as i use some msys-links : / is C:\Dev\msys\1.0 /mingw is C:\Dev\MinGW\mingw /usr/local is C:\Dev\MinGW\local Should that work with GNUstep or do I have to reinstall the whole thing ? Regards Xavier ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Problem building gnustep-base tools with MinGW
>> I suggest following the instructions on core/make/Documentation/README.MinGW. > > That's what i did. Many times :-(( > Which version of the document are you following ? You should follow the one that comes with the version of gnustep-make that you are using. In particular, the one from trunk suggests configuring gnustep-make as: ./configure --with-layout=fhs make make install That would install things into /local/bin, /local/lib, etc. If you're doing anything different than that, you're on your own - ie, you need to know what you are doing ;-) An alternative would be just ./configure make make install Thanks PS: stuff like ./configure --prefix=C:/GNUstep is no longer recommended and might not work. To make things simpler, we prefer people to develop in the clean MSYS/MinGW Unix-like environment where it's guaranteed that there are *no* problems, but making sure the resulting binaries can be then shipped/distributed/organized in some other, more Windows-friendly, way. ;-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Problem building gnustep-base tools with MinGW
Selon Nicola Pero <[EMAIL PROTECTED]>: > > 1) gnustep-make is installed in C:/GNUstep > > That's not really how it is supposed to be used ;-) > > You are supposed to install gnustep-make inside MinGW/MSYS. C:/GNUstep is /C/GNUstep under MSYS (both can be used at MSYS prompt), and that worked fine with my previous installation(s) of GNUstep. AFAIK MinGw applications should even be launched with a mouse click in Explorer (if PATH is set). > I suggest following the instructions on core/make/Documentation/README.MinGW. That's what i did. Many times :-(( > Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Problem building gnustep-base tools with MinGW
> 1) gnustep-make is installed in C:/GNUstep That's not really how it is supposed to be used ;-) You are supposed to install gnustep-make inside MinGW/MSYS. I suggest following the instructions on core/make/Documentation/README.MinGW. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Problem building gnustep-base tools with MinGW
Hi I'm trying to rebuild my GNUstep system from svn. 0) WinXP/MinGW/MSYS, GCC412 1) gnustep-make is installed in C:/GNUstep 2) gnustep-libobjc is installed *Note* : gnustep-libobjc dont work with native_objc_exceptions and base can be linked against gcc-libobjc (is that correct?) 3) ffcall, etc.. are installed 4) gnustep-base fails in linking autogsdoc : it can't find any GS class that have just been built (see log) Thanks for your help Xavier Linking library libgnustep-base ... Info: resolving ___objc_class_name_Protocol by linking to __impobjc_class_name_Protocol (auto-import) Info: resolving ___objc_class_name_Object by linking to __impobjc_class_name_Object (auto-import) Info: resolving __objc_load_callback by linking to __imp___objc_load_callback (auto-import) Info: resolving ___objc_msg_forward by linking to __impobjc_msg_forward (auto-importCreating library file: ./obj/libgnustep-base.dll.a) make[1]: Leaving directory `/c/Dev/gnustep/svn/libs/base/Source' Making all in Tools... make[1]: Entering directory `/c/Dev/gnustep/svn/libs/base/Tools' Making all for tool autogsdoc... Compiling file autogsdoc.m ... Compiling file AGSParser.m ... Compiling file AGSOutput.m ... Compiling file AGSIndex.m ... Compiling file AGSHtml.m ... Linking tool autogsdoc ... gcc -Wl,--enable-auto-import -fgnu-runtime -o obj/autogsdoc.exe \ ./obj/autogsdoc.o ./obj/AGSParser.o ./obj/AGSOutput.o ./obj/AGSIndex.o ./obj/AGSHtml.o \ -L../Source/./obj -L/home/Xavier/GNUstep/Library/Libraries -LC:/GNUstep/Local/Library/Libraries -LC:/GNUstep/System/Library/Libraries -LC:/GNUstep/System/Library/Libraries -LC:/GNUstep/System/Library/Libraries/gnu-gnu-gnu -LC:/GNUstep/System/Library/Libraries -L/usr/local/lib -lgnustep-base -lobjc -lxslt -L/usr/local/lib -lxml2 -L/usr/local/lib -lz -lws2_32 -liconv -lcallback -lavcall -lbfd -liberty -lws2_32 -ladvapi32 -lcomctl32 -luser32 -lcomdlg32 -lmpr -lnetapi32 -lm -I. ./obj/autogsdoc.o(.text+0x67a): In function `main': c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:817: undefined reference to `_imp__GSPrintf' ./obj/autogsdoc.o(.text+0x6ff):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:818: undefined reference to `_imp__GSPrintf' ./obj/autogsdoc.o(.text+0x71a):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:820: undefined reference to `_imp__GSPrintf' ./obj/autogsdoc.o(.text+0x7f5):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:824: undefined reference to `_imp__GSPrintf' ./obj/autogsdoc.o(.text+0x849):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:829: undefined reference to `_imp__GSPrintf' ./obj/autogsdoc.o(.text+0x864):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:830: more undefined references to `_imp__GSPrintf' follow ./obj/autogsdoc.o(.text+0xa14): In function `main': c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:851: undefined reference to `_imp__NSLog' ./obj/autogsdoc.o(.text+0xd3f):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:891: undefined reference to `_imp__NSLog' ./obj/autogsdoc.o(.text+0xdeb):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:904: undefined reference to `_imp__NSLog' ./obj/autogsdoc.o(.text+0xf2c):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:920: undefined reference to `_imp__NSLog' ./obj/autogsdoc.o(.text+0xf66):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:921: undefined reference to `_imp__NSLog' ./obj/autogsdoc.o(.text+0xf7f):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:922: more undefined references to `_imp__NSLog' follow ./obj/autogsdoc.o(.text+0x4184): In function `main': c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:1612: undefined reference to `_imp__NSSearchPathForDirectoriesInDomains' ./obj/autogsdoc.o(.text+0x44d2):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:1654: undefined reference to `_imp__NSSearchPathForDirectoriesInDomains' ./obj/autogsdoc.o(.text+0x4859):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:1703: undefined reference to `_imp__NSLog' ./obj/autogsdoc.o(.text+0x48e4):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:1713: undefined reference to `_imp__NSLog' ./obj/autogsdoc.o(.text+0x560d):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:1878: undefined reference to `_imp__NSLog' ./obj/autogsdoc.o(.text+0x5c15):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:1983: undefined reference to `_imp__NSLog' ./obj/autogsdoc.o(.text+0x5d18):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:1993: undefined reference to `_imp__NSLog' ./obj/autogsdoc.o(.text+0x5ded):c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:1998: more undefined references to `_imp__NSLog' follow ./obj/autogsdoc.o(.text+0x711e): In function `NSMakeRange': c:/Dev/gnustep/svn/libs/base/Tools/../Headers/Foundation/NSRange.h:156: undefined reference to `_imp___NSRangeExceptionRaise' ./obj/autogsdoc.o(.data+0x18fc): In function `main': c:/Dev/gnustep/svn/libs/base/Tools/autogsdoc.m:1051: undefined reference to `__objc_class_name_NSAutoreleasePool' ./obj/autogsdoc.o(.data+0x1900):c
Re: Summer of Code 2007
On 3/16/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: On 3/16/07, Nicola Pero <[EMAIL PROTECTED]> wrote: > > > But... for the sake of the Google SoC, it's probably best if we concentrate on those areas in > > which we are sorely in need of help. Currently, a Renaissance GUI builder would be > > interesting, but not essential. > > It's kind of an upsetting answer for me, but I'll refrain from submitting it as a project then. While I agree with Gregory that it would be better to support Renaissance in Gorm, for SoC, which only last a summer and depends on student's interest, we should not block the option of Renaissance GUI builder. 1. Duplicate work will become an issue only when there is a student who are interested in it. Yes, definitely. Just add the project for the SoC, if somebody is interested it's good anyway. Although I understand greg -- what we would ideally get from the SoC are areas that we need yet where few are working on it at the moment; SoC or a bounty would be in that case possibly a good incentive for people to work on these. In my opinion, these areas for the moment are the windows port (although Xavier works on it now) which is really needed, the Cairo backend (same here, fred is working on it too, but I'm sure he wouldn't mind help), the printing backend, and in general reducing the gap between gnustep and osx... (in addition to adding/improving classes, bindings looks to me like a very cool project for instance). 2. Even there is a student who is interested in it, Nicola can keep the GUI builder modular in case in the future, GNUstep want to support Renaissance in Gorm. So if this Renaissance GUI builder can be more or less in the similar structure of Gorm, or even use the same interface for bundle, to me, it should be an option for students. Well... having looked at Gorm's code and architecture, I'm not sure why we would need a completely different GUI builder. Gorm is very flexible! for me we could easily: - add a gorm palette dealing with the autoresizing widgets (GS*box) - load/import Renaissance files Actually I'm thinking that a nice addition to Gorm could be, instead of a "new application" menu item, have a panel coming up asking you what kind of "gorm file" you are interested in. In that case you could choose a "Renaissance" project, where you'd have the resize stuff all ready for you, for example. Or we could have even more complex projects (like a steptalk-based project where you'd do all your development *in* gorm; or we could imagine a project showing you a palette of stacks and things like that, eg to have something very close to Hypercard, etc.). Remember: Gorm is not a mere GUI builder, it truly is an object relationship modeller ;-) That probably would benefit on a more customizable/flexible palette browser. -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Summer of Code 2007
On 3/16/07, Nicola Pero <[EMAIL PROTECTED]> wrote: > But... for the sake of the Google SoC, it's probably best if we concentrate on those areas in > which we are sorely in need of help. Currently, a Renaissance GUI builder would be > interesting, but not essential. It's kind of an upsetting answer for me, but I'll refrain from submitting it as a project then. While I agree with Gregory that it would be better to support Renaissance in Gorm, for SoC, which only last a summer and depends on student's interest, we should not block the option of Renaissance GUI builder. 1. Duplicate work will become an issue only when there is a student who are interested in it. 2. Even there is a student who is interested in it, Nicola can keep the GUI builder modular in case in the future, GNUstep want to support Renaissance in Gorm. So if this Renaissance GUI builder can be more or less in the similar structure of Gorm, or even use the same interface for bundle, to me, it should be an option for students. It is just my 2 cents. :) Yen-Ju Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Summer of Code 2007
> But... for the sake of the Google SoC, it's probably best if we concentrate > on those areas in > which we are sorely in need of help. Currently, a Renaissance GUI builder > would be > interesting, but not essential. It's kind of an upsetting answer for me, but I'll refrain from submitting it as a project then. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Summer of Code 2007
Nicola, > No, let's not start a new flamewar here, ;-) No one is doing that. I'm not trying to start one by replying, but I just wanted to have a purely technical discussion on this topic. > I did have in mind writing a Renaissance GUI Builder because I'd like to > see a "native" Renaissance GUI Builder where the Renaissance philosophy > is implemented natively. I do believe that that will require new user > interface/design ideas. Ie, I want auto-layout concepts directly built > pervasively everywhere into the basic interface. I feel adding Renaissance > to Gorm (which has a completely different philosophy) will end up in a > patched system that might somehow work but be ugly and meaningless. This is not a true statement. The IBEditors implementations (GormObjectEditor, GormViewEditor and subclasses) control the behavior of each element in the gui while it is being edited. Gorm and IB are not strictly "fixed position" editors. It is not impossible (nor against the paradigm of IB or Gorm, as you suggest) to create an IBEditors implementation that takes Renaissance behaviors into account and even allowed them to dynamically resize the way they should in Gorm. Gorm and IB are open ended gui editors and do not lock you into one given paradigm. That being said, the existing editors and inspectors in Gorm and IB do not currently have this functionality, but only because it's never been implemented, not because it's not possible. When I refactored Gorm to handle nib files, I made it so that the internal data structures were simplified. How Gorm internally stores the gui elements is not necessarily tied to a given format. The nib and gorm and gmodel writer classes all take those data structures and transform them into what is needed for output. The same could be done for .gsmarkup. The only information currently missing in .gsmarkup files is metadata concerning custom classes (i.e. which instances are subclasses of other known classes) and classes added during editing (an equivalent to data.classes in a .gorm package or classes.nib in a .nib). The saving or non-saving of default values also could be built into the editors or even into the writer class which writes the .gsmarkup file out. > Nobody needs to worry anyway as I don't have time to write a Renaissance GUI > Builder myself ... unless I stop working on gnustep-make of course. ;-) I'm not worried, actually, I wouldn't mind seeing something like this happen. What I want to avoid is needless duplication. If a "native" solution is what you insist on, then I would encourage you to take a look at what can be reused from Gorm, since it is a huge amount of work. This would be useful since it could result in the creation of a general GUI builder toolkit of some kind arising out of Gorm's code. But... for the sake of the Google SoC, it's probably best if we concentrate on those areas in which we are sorely in need of help. Currently, a Renaissance GUI builder would be interesting, but not essential. Later, GJC -- Gregory Casamento - Original Message From: Nicola Pero <[EMAIL PROTECTED]> To: Fred Kiefer <[EMAIL PROTECTED]> Cc: Developer GNUstep ; Adam Fedor <[EMAIL PROTECTED]> Sent: Thursday, March 15, 2007 1:56:47 PM Subject: Re: Summer of Code 2007 >> Can we add 'Writing a Renaissance GUI Builder' to the list of tasks ? I >> volunteer mentoring a student doing that. It's a pretty tough job though, >> so >> only determined people! ;-) > > No, lets not write a new GUI Builder here, > No, let's not start a new flamewar here, ;-) Your idea could be good and I respect it, feel free to volunteer for it (or for mentoring it) but it's not what I had in mind. :-) I did have in mind writing a Renaissance GUI Builder because I'd like to see a "native" Renaissance GUI Builder where the Renaissance philosophy is implemented natively. I do believe that that will require new user interface/design ideas. Ie, I want auto-layout concepts directly built pervasively everywhere into the basic interface. I feel adding Renaissance to Gorm (which has a completely different philosophy) will end up in a patched system that might somehow work but be ugly and meaningless. I have nothing against a Gorm pluging for Renaissance though. You can mentor a Gorm plugin for Renaissance if you want. I volunteer to mentor "writing a Renaissance GUI Builder" though. ;-) I also suggest we stop the discussion here and accept that we have different views. We all thought a lot about this and we came to different conclusions. Nobody needs to worry anyway as I don't have time to write a Renaissance GUI Builder myself ... unless I stop working on gnustep-make of course. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-
RE: make install
I dont remember i ever want to install anything in Local... I even had to add to create some links from Local/Tools to System/Tools because some apps only search in System... But i wasn't suprised because it's a standard behavior on Linux : hand build software are installed in /usr/local by default and that's fine. Well... Now i'm affraid i have to reinstall GNUstep. Thanks. Xavier Selon Nicola Pero <[EMAIL PROTECTED]>: > Installing into System is supposed to be the standard ... ;-) > > If you want to always install everything into Local, you can try > > export GNUSTEP_INSTALLATION_DOMAIN=LOCAL > > in your shell (in particular, add it to your shell initialization script). > :-) > > This will then install everything into Local/ ;-) > > Thanks > > > > -Original Message- > From: Xavier Glattard <[EMAIL PROTECTED]> > Sent: Thu, March 15, 2007 9:41 pm > To: gnustep-dev@gnu.org > Subject: make install > > Hi all :-) > > I used to use make-1.13. I just upated it to svn version. > > When i did 'make install' with 1.13 version all files were put in > GNUstep/Local/... directory. But now they are put in GNUstep/System/... > I had to clean by hand my Local directory because it is search first (by ld) > and > old versions of base/gui/... are found. > > What is the 'right' behavior ? > Do i miss something ? > > Thanks ! > > Xavier > > > > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Please digg this, we want GNUstep's Summer of Code participation's place in the limelight!
Am 16.03.2007 um 01:43 schrieb Lars Sonchocky-Helldorf: http://digg.com/programming/ GNUstep_participates_in_Google_Summer_of_Code_2007 http://gnustep.blogspot.com/2007/03/summer-of-code-2007.html about 50 diggs should do it. I think we are half there, already 25 diggs! great work folks, we are already big on http://digg.com/programming/upcoming/cloud regards, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with gnustep trunk
On 2007-03-16 13:04:30 +0200 Nicola Pero <[EMAIL PROTECTED]> wrote: Unfortunately, for me not. I still get: "File NSUserDefaults.m: 580. In [NSUserDefaults +standardUserDefaults] Improper installation: No language locale found" with any application or tool... Thanks Enrico ... I'm not sure why ... can you provide me/us with some more info to find/fix the problem ? :-) It seems that the problem appears when you have an old "/usr/GNUstep/System/Library/Libraries/Resources" together with the new one. Oh ... I see, thanks! :-) Did the problem go away after a clean reinstall then ? :-) Yes, if with "clean reinstall" you mean to remove all your GNUstep directory, as I've done before understanding where the problem was :-) But it is sufficient to remove the old Resources directory. But I've to suppose that *many* people have "$GNUSTEP_SYSTEM_ROOT/Library/Libraries/Resources"; perhaps NSBundle should not try anymore to load resources from it even if it exists... Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with gnustep trunk
>>> Unfortunately, for me not. I still get: >>> >>> "File NSUserDefaults.m: 580. In [NSUserDefaults +standardUserDefaults] >>> Improper installation: No language locale found" >>> >>> with any application or tool... >> >> Thanks Enrico ... I'm not sure why ... can you provide me/us with some more >> info to find/fix the problem ? :-) > > It seems that the problem appears when you have an old > "/usr/GNUstep/System/Library/Libraries/Resources" together with the new one. > Oh ... I see, thanks! :-) Did the problem go away after a clean reinstall then ? :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
