Hi,

for QuartzCore I'll be implementing small command-line tools that in fact open an AppKit window with NSOpenGLView as the content view.

This sort of thing is not officially supported in Cocoa (a bundle is required, or hacks with CPSEnableForegroundOperation() are required). However, it works just fine with GNUstep.

Except for one small error that I just noticed and don't remember seeing before.

"Bad application class '(null)' specified"

Looks like in gui's Source/Functions.m, NSApplicationMain() is explicitly demanding that the bundle and its info dictionary exist, and that NSPrincipalClass is specified, instead of either defaulting to NSApplication, or simply checking whether the class is already initialized.

Since NSApp is a global variable, this should work fine:

Index: Source/Functions.m
===================================================================
--- Source/Functions.m    (revision 35156)
+++ Source/Functions.m    (working copy)
<at> <at> -70,7 +70,7 <at> <at>
   className = [infoDict objectForKey: <at> "NSPrincipalClass"];
   appClass = NSClassFromString(className);
 
-  if (appClass == 0)
+  if (appClass == 0 && NSApp == nil)
     {
       NSLog( <at> "Bad application class '% <at> ' specified", className);
       appClass = [NSApplication class];

Thoughts?
--
Ivan Vučica - ivan <at> vucica.net

Hi all,

For those of you not familiar with the project, the GNUstep-corebase project is a free software implementation of the CoreFoundation library.

I plan on making a release of GNUstep-corebase in a few weeks.  Since this is the first release, and the code is still alpha quality at best, I have decided to do a prolonged testing phase.  This testing phase will be split in 2 subphases.

The first will be a 3 week period, ending June 10th.  This will be the time to test the code and look for inconsistencies.  Essentially, I want to make sure the code compiles in your favorite platform and all tests pass.  New tests can be added to the existing CF-types only, there is no plans to add another type/class before the release.  I will still be doing some work on the library at this time, but do not plan on adding anything new.

The second phase will end on June 24th and will lead to the release.  This is your normal code freeze.  I'd like to get the bugs that were found during the previous phase corrected during this time if they were not already fixed.  I really do not want to add any new tests at this stage unless it is something that can be easily fixed.  Anything requiring a deeper look will be postponed to the next release.

To build -corebase you will need gnustep-make, gnustep-base, libobjc, libicu and the zoneinfo directory.  The dependency on gnustep-base and libobjc will be optional at the time of release.  Being a pure C library, corebase doesn't need these libraries unless you want to interface with the objc runtime (ie toll-free bridged classes).  I have not decided what to do with libicu at this point since it provides core functionality.  If there is enough demand, it will be optional as well.

Adam, would you be able to make the release during the week of June 24th?  I can move the dates around if you need me to.

Thanks
Stef

Hi all,

The script I already mentioned a couple of times is updated, and now also lives in a Mercurial repository instead of on my Dropbox account.

https://bitbucket.org/ivucica/gnustep-ubuntu

It's updated for latest GNUstep (which now seems to require libgnutls-dev), and is verified to work on latest Ubuntu LTS - that is, 12.04 -- that I've switched to. I've also added installation of libxslt-dev, which was not previously installed in the script.

On a 2009 MacBook, longest step of the installation is (naturally) clang, and takes between half an hour and an hour. I'm quite happy with the experience; while the installation process is lengthy, by replacing compiling step of clang with a precompiled version would probably make the installation speedy enough to make a casual Linux user or a new GNUstep developer happy. For now, however, I'm trying to make sure that the installed GNUstep offers the most features, so installing clang from source is probably not a bad idea. (Depending on how much clang is in flux, that is.)

I'd love it if someone would verify the steps that I'm taking and inform me of any extraneous ones.
--
Ivan Vučica - ivan <at> vucica.net

Hi all,

looks like GNUTLS is now a *hard* requirement for -base? Documentation -- that is, the INSTALL file shipping with -base -- still states openssl is an optional install, and doesn't mention GNUTLS in any way.

Having libssl-dev package on Ubuntu installed doesn't help.

I had to install libgnutls-dev to compile; without it, even with libssl-dev, I get the following error:

checking for xsltApplyStylesheet in -lxslt... no

You do not appear to have usable libxslt headers/library.
Building without them will disable the XSLT extensions.
If you really want to build gnustep-base without XSLT support,
add --disable-xslt to the configure arguments to avoid warning.
configure: WARNING: Missing support for XSLT functionality.
checking for libgnutls-config... no
checking for libgnutls - version >= 1.4.0... no
*** The libgnutls-config script installed by libgnutls could not be found
*** If libtgnuls was installed in PREFIX, make sure PREFIX/bin is in
*** your path.
no

You do not appear to have usable libgnutls headers/library.
Building without them will disable SSL/TLS/HTTPS in NSStream
and NSConnection.
If you really want to build gnustep-base without TLS support,
add --disable-tls to the configure arguments.
configure: error: Missing support for TLS functionality.
make: *** [base.make] Error 1

I do see that I can add --disable-tls, but shouldn't that be done automatically? I understand the reasons why one may want to force users to explicitly add this, nonetheless that was not the practice with OpenSSL.

Would --disable-tls also disable the use of OpenSSL?

--
Ivan Vučica - ivan <at> vucica.net

Hi all!