Re: premake (was Re: autoconf / automake)
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: premake (was Re: autoconf / automake)
- From: "Dimiter \"malkia\" Stanev" <malkia@...>
- Date: 2011年10月29日 12:17:25 -0700
Thanks, guys!
I'm looking myself for simple build system, for my hobby project.
I need to compile dozen of open source libs (cairo, pixman, sdl, zlib,
etc.), and I would like to compile them strictly for:
1. MSVCRT.DLL Windows - support goes back to 2000 (if possible, but XP
at least). Also 32-bit and 64-bit. Everything is compiled right now with
Windows DDK 7.1 (yes, the Driver Kit, also called WDK). This is the only
sane free choice that can compile back to MSVCRT.DLL.
- Alternatively I'm looking here at WDK + Platform SDK (Windows SDK
now), as certain C++ things are lacking (for example in AntTweakBar) and
I have to patch manually.
- Or mingw - but there is no stable binary distribution that I would use
- Or take it easy - and reuse the OpenSUSE precompiled binaries - they
have cross-compiled them using mingw - but it's missing some of the
packages I need - apr (Apache) and others
2. OSX - support goes back to 10.4 (10.5 realistically, as no ppc
supported)
- Very strange situation. For example I can locally compile cairo, but
I need macports pixman installed, although later I'm paching
(install_tool_name) cairo to point to my compiled pixman.
3. Linux - I'm not really sure here, I'll probably reuse the package system
4. Mobile - Android, iOS, etc. - it's a bit easier there, if latest
version is only supported. But the actual packages might be hard to compile.
So my biggest hurdle is that each package is compiled differently, some
expect other packages to be present, some are relying on relative paths,
some others to other magic.
For each package, there might be a variation of cmake, scons, jam (ft,
p4, boost, etc.) autoconf, waf, ninja, gyp, make, .dsp, .sln being used,
and not always producing the same thing. I often have to lie to packages
to tell them where the things are, or copy the things for them, or other
magic. Often it works, but then again it fails.
Part of it's my problem - I tend to use latest version of packages,
rather than stable versions, and I'm rethinking whether I should not go
back and use latest stable. Then again I started this whole packaging
experiment so that I can easily test things with luajit+ffi
I ended up with a lot of stupid batch files on Windows, shell scripts
for Linux/OSX.
Unlike rocks (I think), or other distributions I would like this package
to be "USB-pluggable" for lack of a better term - e.g. no install, just
"git clone latest" or unzip and you have it - for all platforms
precompiled (and you would be able to filter out).
On 10/29/11 9:42 AM, liam mail wrote:
On 27 October 2011 22:52, Dimiter 'malkia' Stanev<malkia@gmail.com> wrote:
Has anyone considered using premake?
http://industriousone.com/premake
I have used Premake for maybe 5 or 6 years, ever since coming across
it in CEGUI. Personally I think it is great* and Jason (Starkos) has
made a valuable tool which I use to start any new project rather than
jumping into an IDE.
It's written in "C" but extended through lua.
I do not know if I would agree with this. Most of the C code is
actually Lua itself although there are small pieces of C which are
mostly platform specific, whilst the bulk of the code is actually
written in Lua yet copied to C arrays to make a single binary.
* Biased, I have been committing code to Premake for about a year.