On Sat, Mar 10, 2012 at 09:52:10AM +0900, Miles Bader wrote:
> Any sense on how it compares to quagmire?
>From quick look:
1. Quagmire tries to replace autoconf and libtools too,
Antimake is strictly build tool. It leaves system
detection to autoconf and shared libs to libtool.
2. Despite
On Fri, Mar 09, 2012 at 11:11:56PM -0500, Sam Varshavchik wrote:
> Marko Kreen writes:
> >Antimake is my attempt to fix "no good build system" problem -
> >GNU Make library, but instead inventing custom conventions,
> >it implements Automake syntax.
> >
> >Example:
> >
> > bin_PROGRAMS = hello
> >
Marko Kreen writes:
Antimake already has per-target object files so it should be easy
to add another level of indirection. But I wonder whether it's
actually necessary, as you can always do:
bin_PROGRAMS = foo
noinst_PROGRAMS = foo_debug
foo_SOURCES = ...
foo_C
On Sat, Mar 10, 2012 at 08:54:00AM +0100, Stefano Lattarini wrote:
> On 03/09/2012 11:26 PM, Marko Kreen wrote:
> >
> > Antimake is my attempt to fix "no good build system" problem -
> > GNU Make library, but instead inventing custom conventions,
> > it implements Automake syntax.
> >
> JFTR, we'v
On Sat, Mar 10, 2012 at 01:08:01PM -0500, Sam Varshavchik wrote:
> Actually, my hack was even more generic, and allowed turnkey custom
> definition of arbitrary build modes.
>
> BUILDMODES=prod
>
> was the default.
>
> BUILDMODES=prod debug
>
> was the release+debug build. A rule foreach-ed ove
Hello Marko and all,
Some time ago I start to write something alike, but for cmake and not for make.
I.e. my scripts bunch is dedicated for:
- easer porting to cmake from exists autoconf based build system
- easer write autoconf oriented software
Scripts itself is not a build system but a libr
