[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Porting experience

From: Ibadinov Marat
Subject: Porting experience
Date: Sat, 22 Sep 2012 22:10:13 +0300

As a home project I started to port Sequel Pro to GNUstep. I'm up to describe some issues I've encountered so far.


Generated directory structure:
pbxbuild/ -> ../../Scripts/
During execution scripts have “pbxbuild/<target-name>” as a working directory, end as a consequence relative paths are broken. Simple chdir() should solve the problem. 
Just disabled script execution for now.

On one of targets, I've encountered en error: make: [before-all] Error 127 (ignored). And then execution stops (make.log in attachments). 
Worked-around by removing entire “before-all::” section, but this is not a solution.

Paths in generated *_LIB_DIRS section are not being properly quoted. Corrected it by hand.


Precompiled headers do not work properly: rule is processed, but the resulting object is missing:
error: error opening 'obj/Sequel_Pro.obj/PrecompiledHeaders/ObjC/Source/Sequel-Pro.pch.d': Error opening output file 'obj/Sequel_Pro.obj/PrecompiledHeaders/ObjC/Source/Sequel-Pro.pch.d'
Worked-around by importing Foundation and AppKit explicitly in every source.


Apple's foundation defines NS_INLINE macro in NSObjCRuntime.h as:
#if !defined(NS_INLINE)
    #if defined(__GNUC__)
        #define NS_INLINE static __inline__ __attribute__((always_inline))
    #elif defined(__MWERKS__) || defined(__cplusplus)
        #define NS_INLINE static inline
    #elif defined(_MSC_VER)
        #define NS_INLINE static __inline
    #elif TARGET_OS_WIN32
        #define NS_INLINE static __inline__
This macro is completely missing from GNUstep. But it may be quite useful to ensure desired compiler behavior.
Worked-around by declaring it in-place.


NSCellHitContentArea‘ and NSCellHitTrackableArea’ are completely missing. I'm stuck on this issue, so any help is appreciated.


There is no TargetConditionals.h and AvailabilityMacros.h But this headers may be of use not only by applications, but  also by GNUstep itself.
I don't think there is anything wrong with a program wanting to know on what platform it is compiled or what functionality set it is exposed to.
To solve this problem for Sequel, I created this headers (and extended TargetConditional to include TARGET_OS_LINUX, TARGET_OS_BSD etc.).

Also there was nasty dependence of RegexKitLite on OSAtomic API provided by libkern.
Obviously, there was an option of resorting to NSLock, but what is conceptually wrong with a library that want to use atomic operations and spin locks
for better performance? And why would you allow the kernel to preempt your thread if you only need to perform some shared-hash-table lookup or 
any other inherently fast operation in a safe manner? I suppose nothing.
At this stage I've managed to create PThread.h header that wraps OSSpinLock from libkern into pthread_spinlock API on OSX and created OSAtomic.h that
wraps necessary function form HP's libatomic-ops into libkern's API  on Linux to get working version of RegexKitLite.
Here's the question that is distressing me:
Is it rational (or even possible) to create some API that wraps libkern/OSAtomic.h on OSX, machine/atomic.h on BSD, atomic.h on Solaris, 
Interlocked* on Windows and libatomic-ops on Linux to provide cross-platform way of threading optimization?
Hope to hear any opinion on this subject from somebody who is more experienced in this low-level things. David?

P.S. Nonetheless, experience is pleasant.

Attachment: make.log
Description: Binary data

Attachment: pch.log
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]