[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] Lake 1.2, a Lua-based Build Tool
- From: Graham Wakefield <wakefield@...>
- Date: Sat, 21 Jan 2012 12:22:24 -0800
> On Sat, Jan 21, 2012 at 12:53 AM, Graham Wakefield
> <wakefield@mat.ucsb.edu> wrote:
>> Somehow the linker needs to know that a dependency of XXX.framework should issue linker command -framework XXX
>
> I do Windows/Linux, and my experience of OS X is limited to my wife's
> elderly Tiger PPC machine. So the current incantation for linking
> shared libraries is probably getting equally elderly (Like the target
> set to 10.3 etc). So I'd like some advice on how to update Lake so
> that it can track the changes in the latest OS X.
>
> The 'needs' mechanism is biased towards traditional include/link path
> and libs; I'd have to think about how this could be generalized to
> generate appropriate link commands.
I think supporting frameworks is pretty essential for OSX, which I hope shouldn't be too hard to add. A framework thing is basically a wrapper around a dynamic library + headers, and is handled by Apple's version of gcc/g++.
The search path for frameworks (for both compiler headers and linker libraries) is specified with -F rather than -L, and the standard search paths are /System/Libraray/Frameworks/, /Library/Frameworks/, and ~/Library/Frameworks/
Linking a framework is specified as -framework XXX.framework (instead of -lXXX, note the space).
I looked at lake.lua to try to figure out where this should be added, but it wasn't immediately clear; however if you give me a few pointers (offlist probably better) I can take a stab at it, and test it on a few macs here.
[[ There are a few other OSX 'features' (quirks?) that might be nice to add, such as the universal building (one or more flags of the form -arch i386 -arch x86_64), and various was to specify the SDK to depend on / support (-mmacosx-version-min, -isysroot, etc.). ]]
On Jan 21, 2012, at 1:24 AM, steve donovan wrote:
>
> As an auto-criticism, Lake is far too monolithic at the moment; an
> oversized script; it needs modularization and more customization hooks
> to become a program.
On the other hand, being a single 48k Lua file makes it very convenient to simply drop into the source tree of every project that uses it...