Can we disable the alert email when everything is OK ?
Or maybe only send it to Adam (or some volunteers) so he knows
that the testing system is running ?
Thanks
-Original Message-
From: "Adam Fedor" <[EMAIL PROTECTED]>
Sent: Wednesday, November 29, 2006 12:34 pm
To: gnustep-dev@gnu.or
> Someone on irc was wondering about ctools and c++ files,
> clibrary.make seemed to work ok though.
>
> it doesn't seem to currently include $(CC_OBJC_FILES).
> attached is a patch for that..
Thanks ... good stuff ... I cleaned it up so it's a bit more general,
and committed. :-)
> additionally
> ... but heres another thing
>
> documentation.make installs TEXI_FILES files into
Library/Documentation/info
> heres a patch to set this up in the INFOPATH env var from GNUstep.sh
Thanks ... I applied the patch (with a few subsequent tidyups), seems to
work nicely. ;-)
Thanks
> i suppose ther
> I just commited a fix for a paste error $gnustep_class_path instead of
> $gnustep_info_path so only System/Library/Documentaion/info was getting set
Whoops ... thanks! :-)
> Yeah, i do notice that GNUstep.sh.in uses Library/Libraries/Guile
> though and GNUstep.csh.in uses Libraries/Guile
Oh
I also suggest that we make a new release of gnustep-make.
Thanks
-Original Message-
From: Gregory John Casamento <[EMAIL PROTECTED]>
Sent: Sat, January 13, 2007 9:38 pm
To: Fred Kiefer <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Richard Frith-Macdonald
<[EMAIL PROTECTED]>
Cc: gnustep-dev@
I updated Renaissance to use this -- on my machine it now builds twice as fast
with GCC 3.4.6, so precompiled headers seem to work fine if your compiler
supports it! :-)
Thanks
-Original Message-
From: Nicola Pero <[EMAIL PROTECTED]>
Sent: Tue, January 16, 2007 3:20 am
To: d
I want to make a gnustep-make release. It would be 1.14.0.
What is the current workflow to do that ?
Thanks
-Original Message-
From: Gregory John Casamento <[EMAIL PROTECTED]>
Sent: Mon, January 22, 2007 8:15 am
To: GNUstep Developers
Subject: Delay of release
All,
My sincerest
> Here's the procedure for actually making a release:
>
> http://wiki.gnustep.org/index.php/GNUstep_release_procedure
>
Ok ... thanks. I suppose for gnustep-make I can do all the steps up to tagging
the release, then you or Gregory will send out announces and manage the release
publishing ?
I'd
> attached is just sort of an experiment in getting rid of GNUstep.sh to
> compile stuff
If you use trunk, you don't need GNUstep.sh to compile stuff ... ;-)
1. add /usr/GNUstep/System/Library/Libraries and
/usr/GNUstep/Local/Library/Libraries to /etc/ld.so.conf and run ldconfig
2. add /usr
> GDL2 needs to attempt to link to the Gorm libraries to see if it
> should enable building of the GDL2 Gorm palette
> and in porting aquaterm, and the gnuplot adaptor for aquaterm, it
> needs to also look for a lib in the GNUstep heirarchy
> to enable that.
There are two solutions to that:
1
> It's not stricty GDL2 in this case but ./configure of GDL2 which want to
> tweak make file fragments dependent on what's available. So maybe we
> need some tool in the path to query the values. Something like
> gnustep-config akin to apxs and xml2-config.
Such a tool/shell script would be goo
> 1. source GNUstep.sh inside ./configure.
> 2. do it inside your GNUmakefile directly ...
Thinking about it, I'm not really with any of these two solutions ... when we
change radically the location of libraries, both might be broken by the change.
;-)
Probably the best solution is to add a
> so the idea was we replace all the environment variables with that we
> install gnustep.pc by default into somewhere pkg-config will find it, then
> people who want non-standard stuff fiddle with it can set PKG_CONFIG_PATH
> but it should just work by default
I'm a bit confused ... it looks l
> but my main problem with GNUstep.sh isn't actually technical at all,
> its the very first thing potential developers are going to see, so
> will be the first impression,
> and imho gives the impression of being strange because it is uncommon
> for a build system to depend on environment variab
> Yes. The thing we do (... ;-) is to have a very small (hand written)
> 'configure' script which locates gnustep-make and writes a small
> 'config.make' files containing the relevant GS variables. Then all
> makefiles include that config.make file like this:
>
> -include config.make
> incl
Thanks for your suggestions
You seem to think that the current solution lacks:
1. a way to compile without setting GNUSTEP_MAKEFILES
2. a way to get the GNUstep bundle/libs/tools search paths for use in
configure scripts etc.
I agree we can do better to address those. Solutions that came to
> Personally I'd prefer to suspend the release until we have an
> environment that has a chance of remaining stable. It seems that we
> already require -make users to adapt thier projects for this release (I
> remeber you cleaning up many projects in SVN) and it seems they may need
> to adapt aga
I'm a bit confused by your email. ;-)
I guess it simply shows that most people are not aware of the 'radical'
filesystem-independency plan that we have been working on in gnustep-make and
gnustep-base for the past few years! ;-)
> Wouldn't it be possible to change make so that it handles both
>> So we could have a small makefile fragment, let's call it find-
>> gnustep.make,
>> that searches for gnustep-make on disk and sets GNUSTEP_MAKEFILES
>> to the best
>> match. I'll write that makefile fragment, and it will be
>> maintained inside
>> gnustep-make.
>
>I don't get this one, yo
> Right, and also, frankly, there's a very important non-technical aspect
> to this as well; Way more developers know what the heck .pc files and
> pkg-config are, as well as how they work, than a funky GNUstep.conf
> file, which, while somewhat self-explanatory, definitely is proprietary.
> p
>> If we had gnustep-make depend on pkg-config, then you wouldn't be
>> able to use GNUstep unless you installed pkg-config first.
>
> That's not entirely correct. GNUstep can be taught how to read
> pkgconfig-format-file, such as GNUstep.pc, thus eliminating the need
> for GNUstep.conf enti
> a quick test of a makefile executing pkg-config 1000 times takes about 6
> seconds..
> say there are 5 invocations of pkg-config per invocation of make... thats 200
> make
> processes.
Wow - that would be a massive overhead ... for just reading config (ie, doing
nothing
useful, only bootstr
> Third, Nicola keeps on claiming in this thread that a standard GNUstep
> could be compiled by just setting the values in GNUstep.conf and doing
> nothing else. This does not work for me, I still need to source
> GNUstep.sh to get things working. Otherwise the compilation of gui
> complains that
> The only objection i've heard from gnustep.pc is "Its not the way
> GNUstep stores information".
Here is a refresher --
1. it adds an external dependency upon which *everything* would depend
2. it is slower
3. it is designed for something else (which adds complexity)
4. it requires rew
I like the idea of your patch, so I rewrote the shell script and committed it.
Thanks!
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
> so can we change everything to
>
> GNUSTEP_MAKEFILES ?= $(shell gnustep-config.sh GNUSTEP_MAKEFILES)
> include $(GNUSTEP_MAKEFILES)/common.make
I think it's a good suggestion, even if I'd change it (slightly) to be
ifeq ($(GNUSTEP_MAKEFILES),)
GNUSTEP_MAKEFILES := $(shell gnustep-config.sh GN
>> I like the idea of your patch, so I rewrote the shell script and committed
>> it.
>
>
> Minor nit... isn't gnustep-config.sh meant to be executed, not sourced?
> So shouldn't it be named gnustep-config instead of gnustep.config.sh?
Yes, it is meant to be executed, not sourced. Not sure what
>> Did you add your System Libraries directory and your Local Libraries
>> directory to /etc/ld.so.conf ? Did you run ldconfig after installing
>> any new library ? If not, it won't work.
>
> That's the same for lots of non-gnustep stuff too, but mostly non-
> gnustep stuff seems to avoid the p
>> * How we decide if we have to run ldconfig or not ? Do we need to
>> run it only on GNU/Linux ? Are there similar tools on other
>> unixes ? (I imagine so, so we'll have a general-purpose post-
>> library-install target-dependent command that we run automatically)
>
> I'm pretty sure ev
> IIRC we had some extensive discussions on the mailing lists that
> .sh/.csh should only be used for scripts that are sourced. But since
> GNUStep.sh is referenced so often in the archives, I'm having a hard
> time finding the discussion.
I don't remember that discussion, but it's plain obvious
: gnustep-make experiment
On 12 Feb 2007, at 15:51, Nicola Pero wrote:
>
>>> * How we decide if we have to run ldconfig or not ? Do we need to
>>> run it only on GNU/Linux ? Are there similar tools on other
>>> unixes ? (I imagine so, so we'll have a g
> But I actually want to clarify what I meant with the third option for
> the configure issue... My goal is to have ./configure of GDL2 identify
> whether libGorm is installed/usable so it can decide whether the palette
> should be build or not.
>
> (The servers I deploy my GSWeb App on do not h
(discussion about how to get the compile/link flags out of gnustep-make)
> That's the kind of functionality we need and a usage style familiar to users
> of pkg-config (and convenient for use with the autoconf macros). Another
> option is to just use pkg-config and bundle it with gnustep-make
> - this search would be executed for /every/ make invocation instead of
> once during configure.
It would be really slow if we were trying to compile something against the
library
for every make invocation. Subprocesses are very slow, and the compiler is
particularly slow. :-/
But if we're j
> I like this one. In fact, you could have a msg like this:
>
> GNUstep make (version x.xx); please type "make help=yes" for help.
>
> That would serve 3 purposes -- tell invoker that GNUstep make is being
> used (in case they care), the version, and how to get help.
Thanks ... that was a g
>> You can have non-flattened multi-platform installations that are
>> mounted from
>> the network; the same gnustep-make will then use different
>> compilation
>> flags/tools for the different hosts (keep in mind that each host
>> might also
>> have a different
>> filesystem configuration,
>> Because we don't even store fixed sets of flags, but we compute them
>> dynamically,
>> using pkg-config to print them is more of an additional problem
>> than a solution.
>
> I forget exactly how non-flattend looks having not used it since the
> default changed...
>
> but heres an example o
> 1) Is pkg-config critical to the goal of FHS compliance?
No.
> 2) Can we leverage it to simplify gnustep-make?
No, but you can leverage it to make it even more complicated! ;-)
Thanks
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists
I think I fixed those now. :-)
We need to make sure we never reference the GNUSTEP_INSTALLATION_DIR variable
(which
isn't available any more if you install using GNUSTEP_INSTALLATION_DOMAIN,
which is
what we are doing everywhere on the GNUstep trunk).
Instead we should use GNUSTEP_APPS, GNUSTEP
> Fail Compile i386-unknown-freebsd6.2 Wed Feb 14 18:48:44 CST 2007
> Fail Compile i386-unknown-netbsdelf3.1 Wed Feb 14 03:54:18 CET 2007
> Fail Compile powerpc-apple-darwin8.8.0 Tue Feb 13 13:00:36 CET 2007
> Fail Compile sparc-sun-solaris2.7 Wed Feb 14 01:27:02 EST 2007
> Success Compile x86_64-
> Fail Compile i386-unknown-netbsdelf3.1 Thu Feb 15 03:54:19 CET 2007
According to the logs, the reason for this was --
config.status:753: creating config-noarch.make
config.status:753: creating config.make
config.status:753: creating openapp
config.status:753: creating opentool
config.status:75
This patch rewrites some internal code (making it more complex, not more easy,
but I suppose it's a matter of taste) and the only visible effect I can see is
that
it destroys the non-flattened (ie, fat binary) support in gnustep-make. :-(
Fat binaries *will* be/are supported in gnustep-make v2,
> No that should still work..
Hard to believe. So you're compiling a C tool and then hope to use
the compiled executable without change on all the cpu/os that we support ?
We managed to get rid of all C tools in gnustep-make in October 2006, and that
was a good step in terms of simplification:
Matt, thanks for your comments.
I understand your desire to centralize the configuration, but there
is an actual reason why GNUstep.sh is a pure shell script. ;-)
It's a machine-independent program that can be in a machine-independent
directory
and that can then be used to bootstrap the fat bin
Thanks ... it's quite interesting, as the problem might be a bug in GNU make.
:-)
I'll take the warnings out until the situation is clarified.
Thanks
-Original Message-
From: Fred Kiefer <[EMAIL PROTECTED]>
Sent: Sun, February 18, 2007 8:49 pm
To: [EMAIL PROTECTED]
Cc: Developer GNUst
bruary 27, 2007 12:17 pm
To: Nicola Pero <[EMAIL PROTECTED]>, GNUstep Developer
Subject: Compiler warnings for the cairo backend
Hi Nicola,
starting with your changes to the GNUstep make system, I am now getting
loads of warnings when compiling the cairo backend:
Compiling file CairoSurfa
Ok ... I had to start Windows up to check some web pages under IE 7, and
then since I was there I thought I'd give another try to GNUstep on Windows.
It looks pretty cool.
I updated the core/make/Documentation/README.MinGW file on trunk. Please note
that (between other things) the recommended fil
> I *think* it used to open the server preferences panel rather than
> pop up an alert panel ... not sure why that's happening.
> Also, it should only happen first time ... so if it keeps happening
> then there is a bug somewhere.
I think at the moment it boths pops up an alert panel *and* th
with a different location for each domain ?
Thanks
-Original Message-
From: Richard Frith-Macdonald <[EMAIL PROTECTED]>
Sent: Tue, March 6, 2007 8:34 am
To: Nicola Pero <[EMAIL PROTECTED]>
Cc: GNUstep Developer
Subject: (no subject)
While looking at a bug in the way the
>> - in my patch handlesWindowDecoration (like X11?) and
>> usesSystemTaskbar are
>> set by default : do you agree with these choices ?
>
> Yes but ... I expect the person who added the application preferences
> panel did so because people want a variety of behaviors ... so I
> think that
For NSUserDirectory we probably only need System, Network and Local -- the User
domain
would not make sense as it would mean you can put user's directories in your
own user directory. :-/
(Mac OS X has only got Network and Local)
OK, I'll add them now.
Thanks
__
> > > Yes but ... I expect the person who added the application preferences
> > > panel did so because people want a variety of behaviors ... so I
> > > think that removing that panel without providing a better alternative
> > > is a mistake. Unfortunately I don't know what the better altern
> Previously, I used to put this in the GNUmakefile (like GNUMail does,
> except that it puts them directly in Library):
>
> BUNDLE_INSTALL_DIR=$(GNUSTEP_INSTALLATION_DIR)/Library/Bundles/Paje
>
You can use
BUNDLE_INSTALL_DIR = $(GNUSTEP_BUNDLES)/Paje
to get exactly the same result (nice thing
>> 007-03-12 22:54:13.577 GSTest[29400] File NSUserDefaults.m: 552. In
>> [NSUserDefaults +standardUserDefaults] Improper installation: No
>> language locale found
>
> I had some weird problems after installing GNUstep from trunk last Sunday.
> But after re-compile every application, it turns ou
> I just tried reinstalling everything from scratch and I don't get that error.
Actually, it turns out that I had already figured out this problem and fixed it
(by rewriting resource-set.make), but I forgot to commit the rewrite.
So of course gnustep-base localizable resources worked fine for me
branch as well, right?
On Mar 13, 2007, at 2:56 AM, Nicola Pero wrote:
> Author: nicola
> Date: Tue Mar 13 09:56:51 2007
> New Revision: 24856
>
> URL: http://svn.gna.org/viewcvs/gnustep?rev=24856&view=rev
> Log:
> Committed rewrite of resource-set.make that I had forgotten
>> Well, bytes value is "février" (in iso-8859-1 I think) and comes from
>>
>> [NSString stringWithUTF8String: nl_langinfo (MON_1+1)]
>>
Maybe we need to use nl_langinfo(CODESET) instead of UTF-8 to interpret the
bytes ?
(no idea, didn't have time to really look up the doc)
> If I use C (or
make messages=yes
will display exactly the command-line commands used to compile and link; you may
want to try it out and compare those with the ones you use yourself ... that
might
provide some light on what the problem could be. :-)
Thanks
-Original Message-
From: Michael Gardner <[
> 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 fin
>> You still have to compile your program with -fexceptions to get "objc"
>> exceptions working with objective-C.
>
> But that doesn't explain (2), where I *do* use -fobjc-exceptions, only
> with gcc instead of g++, and with a separate linking step instead of
> all-at-once.
I believe that Andrew
> Andrew -- do we need to add -fexceptions on all platforms or only on some ?
Well, I added it to all platforms on gnustep-make trunk. :-)
If anyone has got a FreeBSD (or any other non-GNU/Linux platform) and is around
to help
a little, you could try gnustep-make from trunk, using
./configure
I looked at the stuff, and the money is pretty good for students -- it looks
like
it's 4,500 USD in total for the Summer job ? :-)
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
determi
>> 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 id
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/ ;-
>>> 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 m
> 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 submittin
> 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
___
G
>> 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
>> ./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
That's brilliant ... I added --shared-libgcc (on all platforms) to the linking
stage when
native ObjC exceptions are enabled. :-)
Hopefully that fixes it ... Michael, any chances you could try it out with
gnustep-make from trunk to see if it's fixed now ? :-)
Thanks
PS: Please let me know if th
I rebooted under Windows XP and I can't reproduce your problem at all - it
links fine for me (I removed the installed gnustep-base before trying). :-(
So I'm not sure why it doesn't work for you.
The only differences between my case and you case are ... my GCC is 3.4.2
while you mention that yo
>> That's brilliant ... I added --shared-libgcc (on all platforms) to the
>> linking stage when native ObjC exceptions are enabled. :-)
>>
>> Hopefully that fixes it ... Michael, any chances you could try it out with
>> gnustep-make from trunk to see if it's fixed now ? :-)
>
> That might be diffi
>> Mine is:
>>
>> 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/Nico/GNUstep/Library/Libraries
>> -L/usr/local/lib -L/usr/local/lib -L/
> Today, after a svn update, the problem is again here... (on four
> different machines) (I do have a
> "/usr/GNUstep/System/Library/Libraries/gnustep-base/Versions/1.14/Resources/Languages")
Thanks ... we clearly haven't finished fixing this yet :-(
The directory is looked up in various place
> [EMAIL PROTECTED] ~]# make_services
> 2007-03-20 15:38:12.039 make_services[23877] File NSUserDefaults.m: 580. In
> [NSUserDefaults +standardUserDefaults] Improper installation: No language
> locale
> found
OK ... I debugged and rewrote the lot ... try again now. :-)
Thanks
_
>Hi,
>
>I want to propose changes to gui-trunk (patch attached). In general
>changes are touches NSMattrix and NSCell and is about drawing first
>reponder indicator (dotted frame). What is done:
>
>- NSCell is responsible for showing first responder state;
>- Removed code from NSMatrix which sets
>> I'm sure you have a reason to propose this change ... probably a good idea
>> to explain it. ;-)
>>
>> ie, what's wrong with the existing code ? :-)
>
> I think I've explained more in detail in response to Fred's mail.
> If you have other questions just ask me. Thank you.
No problem, thanks fo
>I don't have *any* experience in building dll ;-)
>And building gcc-libobjc as a dll might break some other thing...
>So i give up and let this task to others, even if i could not use
>'native exceptions'.
Why do you need gcc-libobjc for 'native exceptions' ? Are there any
missing changes in gn
> Do i miss something ?
I think there might be a bit of confusion ... let me explain ;-)
If you want to try native exceptions on MinGW, you should:
1. install MSYS/MinGW
2. build/install a GCC 4.x that provides you with native exceptions
3. make sure this new GCC is the compiler that will
> I've did that many times. gnustep-make configure script tells me :
>
> checking for custom shared objc library... /c/GNUStep/System/Library/Libraries
> checking whether objc has thread support... yes:
> checking whether we should use native ObjC exceptions... no
> configure: Native objective-c
> Wouldn't it still work, if you installed make the first time with no
> special options (just so libobjc could use it), then do a proper
> installation afterwards - that's what I do all the time with gnustep-
> startup:
I'm not sure - it would mean you compile/link libobjc without using
-fe
Or branch again ;-)
Anyway, gnustep-make (and the corresponding bits in gnustep-base)
should be ready for release now ... I'm not aware of any more
problems.
We just need to prepare the release notes.
Thanks
-Original Message-
From: Fred Kiefer <[EMAIL PROTECTED]>
Sent: Thu, March 29,
Thanks Tim!
I fixed the 'mac' file system layout as you suggested :-)
I think Richard made a change to NSPathUtilities.m to fix the case of empty
paths.
Hope that fixes your problems, if not, let us know! :-)
Thanks
-Original Message-
From: Tim McIntosh <[EMAIL PROTECTED]>
Sent: Fri
Hi Marco,
1. the info files are installed in the path that you decide when you choose the
filesystem layout when you configure gnustep-make. ;-)
Check the filesystem layouts inside core/make/FilesystemLayouts/ (you are
looking
for the keys 'GNUSTEP_SYSTEM_DOC_INFO', 'GNUSTEP_LOCAL_DOC_INFO', etc
eate the symlink only for old
gnustep-makes.
The relevant change is the following one --
2007-03-06 Nicola Pero <[EMAIL PROTECTED]>
* Instance/framework.make: When version support is enabled, build
symlinks from top-level xxx.framework/TARGET_LDIR/xxx and
xxx.framewo
Are you sure this is the right mailing list for your problem ? ;-)
This is a mailing list for GNUstep developers. :-)
Anyway, trying to guess what you're trying to do,
are you compiling/linking a C file ? Then you probably
don't want to use g++ or libstdc++, which are used for C++.
Thanks
y source code is in C and i tried using gcc and removed libstdc++ but
then it gives the error mentioned in previous email.
Can you please advice
Thanks
On 4/11/07, Nicola Pero <[EMAIL PROTECTED]> wrote:
> Are you sure this is the right mailing list for your problem ? ;-)
>
>
Good idea ... probably amit hetawal could try it by doing
something like --
$(TARGET): $(OBJECTS)
g++ -g -o $(TARGET) $(OBJECTS) $(LDFLAGS)
coral_test.o: coral_test.c Makefile
gcc $(CPPFLAGS) coral_test.c
Thanks
-Original Message-
From: Wolfgang Sourdeau <[EMAIL PROTECTED]>
Sen
PS: ffcall is not built using gnustep-make ;-)
Presumably you configure it using
./configure --prefix=/usr/GNUstep/System
and you notice that that would install the lib into
/usr/GNUstep/System/Library/Libraries with
gnustep-make v1 and now it installs the lib into /usr/GNUstep/System/lib.
Wh
Not sure if Bjorn received my patch or applied it, so just resending out to dev
and
if anything is working on that at least they can reuse it
Thanks
-Original Message-
From: Nicola Pero <[EMAIL PROTECTED]>
Sent: Wed, March 7, 2007 8:02 pm
To: Björn Giesler <[EMAIL PROTECTED]
Hi Tim,
from the stacktrace that you provided, it seems that the problem is in NSString
+initialize.
In particular, you're getting the following exception:
#ifdef HAVE_REGISTER_PRINTF_FUNCTION
if (register_printf_function
Here is a patch to update Backbone to work with gnustep-make v2 (and FHS, etc).
I'm sending it to the mailing list so that it doesn't get lost. ;-)
Thanks
diff
Description: Binary data
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.o
On May 8, 2007, at 11:14 PM, Riccardo wrote:
Hi,
trying to compile NSAnimation on older compilers is a nightmare
(like gcc 2.95). I fixed some trivial stuff, but then stopped: the
main problem is the _NSANIMATION_LOCK macro. Since this macro
defines a variable in it,
#define _NSANIMATI
Sorry, forgot to put the mailing list in Cc:
Thanks
Is there a flag we can pass to ask GCC to refuse c99-isms ?
There must be one.
-std=c89 or -std=gnu89 depending on whether we want to permit GNU
C extensions.
Nicola answered:
Actually, they seem to work -- the problem is that -std=g
This looks pretty bad, not only because it doesn't compile with GCC
2.95, but also because that variable defined in the middle of
nowhere is very ugly ... unclear
scope (what happens if you have two _NSANIMATION_LOCK in
sequence ? is the same variable being used or different
variables ?) ...
T
> If we decide to move to the new license, then my opinion on the best way for
> the
> project to proceed is to change the license of our applications (GWorkspace,
> Gorm,
> etc) within GNUstep itself to the GPLv3 license. All of the libraries
> should
> remain LGPL.
You probably mean tha
> what should happen to make? As far as I remember there was only one tiny
> issue
> fixed in make.
> The only reason for a release would be the license switch.
A license switch is enough to deserve a new release ... even if just a subminor
one.
Thanks
_
Yes, excellent idea - it would be good to commit it. :-)
(I even thought we already had ADDITIONAL_NATIVE_LIB_DIRS, but actually we
don't
have it yet!)
Thanks
-Original Message-
From: David Ayers <[EMAIL PROTECTED]>
Sent: Tuesday, October 30, 2007 9:17pm
To: GNUstep Developer
Subject:
I tagged the latest jigs from subversion and made a 1.5.7 release.
Thanks
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
> I develop vespucci under PC. It uses the SimpleWebKit framework. It
> compiles fine under windows, [...]
> I notice something though: when using a framework I need to include
> its library in PC. This causes the following GNUstep.preamble:
>
> # Additional flags to pass to the linker
> ADDITIO
1 - 100 of 440 matches
Mail list logo
