Re: autotools alternatives, is anybody using autosetup?

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Sam Roberts
On Fri, Oct 28, 2011 at 7:22 PM, Michael Richter <[hidden email]> wrote:
> The Fossil[1] community had this whole process not all that long ago.
> Automake/autoconf were rejected as not being portable and being in general a
> complete pain in the lower torso anatomy to use.  The solution that was used
> in the end was a little piece of software called autosetup[2].

Has anybody been using autosetup with lua projects?

I've been playing with it. I've had trouble finding a decent tcl
syntax summary, but its not like I know m4 very well, either.

I quite like it. I particularly like that it does the part that make
does poorly: feature discovery, build parameterization, outputting a
config.h, and injecting discovered values into the template Makefile.
Much, much easier to understand, and easy to apply to existing
projects.

I've just been playing around with it in a stub project, trying to see
if it can do the lua header file discovery that every lua binding so
annoyingly needs to do. Result is here:

https://github.com/sam-github/udns-lua/blob/master/auto.def

Is anybody else using autosetup with lua? If there are public repos,
I'd like to see more examples.

Btw, I also looked at premake, and its pretty much exactly what I
don't want, a replacement for make, that controls all aspects of the
build. Nice that its in lua, but no...

Cheers,
Sam


> [2]: http://msteveb.github.com/autosetup/

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

William Ahern
On Mon, Jul 16, 2012 at 05:32:59PM -0700, Sam Roberts wrote:

> On Fri, Oct 28, 2011 at 7:22 PM, Michael Richter <[hidden email]> wrote:
> > The Fossil[1] community had this whole process not all that long ago.
> > Automake/autoconf were rejected as not being portable and being in general a
> > complete pain in the lower torso anatomy to use.  The solution that was used
> > in the end was a little piece of software called autosetup[2].
>
> Has anybody been using autosetup with lua projects?
>
> I've been playing with it. I've had trouble finding a decent tcl
> syntax summary, but its not like I know m4 very well, either.

M4 is deviously simple. It's autoconf that makes M4 seem difficult and
arcane.

<snip>
> I've just been playing around with it in a stub project, trying to see
> if it can do the lua header file discovery that every lua binding so
> annoyingly needs to do. Result is here:
>
> https://github.com/sam-github/udns-lua/blob/master/auto.def
>

The better alternative to autoconf is usually nothing, IMO.

For example, your include script is pretty trivial to do with the shell.
Unlike the 1980s and 1990s, Unix environments are significanly more
homogenous. There're very few headaches supporting the *BSDs and Linux. And
if you rigorously stick to POSIX then scripts almost always work elsewhere.
Most of the headaches I've had turned out to be my non-POSIX compliant
scripts.

Predefined CPP macros can handle most feature discovery tasks, and it's far
easier for others to contribute, and for you to integrate, experiential
knowledge. See, e.g.

        http://sourceforge.net/apps/mediawiki/predef/index.php?title=Main_Page

(I realize feature probing is preferable to version testing, but not at any
cost. And for those cases where it's clearly preferable it's fairly easy to
generate code from probes using Make.)

More importantly, sometimes it's best to just require the user to provide a
parameter. The infrastructure to do this automagically seems to get in the
way more often than it helps, especially for oddball cases, which ironically
is really the selling point** of using these tools. For example, I keep my
Lua headers under include/lua/5.?, similar to module paths and as god
intended. So your autosetup script would appear to fail in that case, plus
in other more common cases, like /opt or using separate project dirs under
/usr/local, like in the old Slackware days.

Autoconf may have given M4 a bad name, but there's nothing wrong with
multistage source generation, IMHO.

Finally, if you're trying to be portable to Windows then you're already
doomed to a fate worse than death, so the fact that the above points fail is
hardly consequential ;)


** That's the main selling point to the users. Distributions like them
because they tend to prevent the user from screwing up cross-compiling.
OTOH, if the build is relatively simple then it should be relatively simple
for the porter to fix. And the less stuff your build does to introspect the
environment, the fewer issues there'll be to fix in the first place.


Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Miles Bader-2
William Ahern <[hidden email]> writes:
> M4 is deviously simple. It's autoconf that makes M4 seem difficult
> and arcane.

Naw, typical autoconf files are very straight-forward.

> The better alternative to autoconf is usually nothing, IMO.

This is only true for the most trivial cases (which, to be fair, may
include many lua projects), and often not even then, because even
trivial autoconf files are usually much simpler than the equivalent
shell-script.

Remember, autoconf input files _are_ essentially shell scripts, except
that they give you easy mechanisms to accomplish common configuration
tasks; you choose the degree to which you use these mechanisms though.
Writing everything yourself in shell is obviously possible, but
typically means you just end up simply duplicating what the autoconf
authors have done, usually in a less functional, more buggy, and less
portable way.

-miles

--
Quack, n. A murderer without a license.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Coda Highland
On Mon, Jul 16, 2012 at 11:19 PM, Miles Bader <[hidden email]> wrote:
>> The better alternative to autoconf is usually nothing, IMO.
>
> This is only true for the most trivial cases (which, to be fair, may
> include many lua projects), and often not even then, because even
> trivial autoconf files are usually much simpler than the equivalent
> shell-script.

Would you consider LuaJIT to be a "trivial" case? It doesn't use
anything but straight-up "make".

I'm going to have to agree: autoconf is an unnecessary extra step in
software deployment on modern systems, and one that slows down build
times for little tangible benefit.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

steve donovan
On Tue, Jul 17, 2012 at 7:26 AM, Coda Highland <[hidden email]> wrote:
> I'm going to have to agree: autoconf is an unnecessary extra step in
> software deployment on modern systems, and one that slows down build
> times for little tangible benefit.

Yes, I have to side with William on this one.  From a user
perspective, the output of './configure --help' is very daunting, and
the key custom configuration parameters (like where your non-standard
Lua is) are hidden n the noise.

Another option is to use Lua for generating the makefile, or at least
the .inc files.  Yes, there is a fair amount of support code (I find
myself coding which() far too often) but that can go into a relatively
small support module that ships with the build. Being inside Lua also
means that you know your module path, etc.

And then you have a fighting chance of getting a cross-platform build working ;)

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Miles Bader-2
In reply to this post by Coda Highland
Coda Highland <[hidden email]> writes:

> On Mon, Jul 16, 2012 at 11:19 PM, Miles Bader <[hidden email]> wrote:
>
>>> The better alternative to autoconf is usually nothing, IMO.
>>
>> This is only true for the most trivial cases (which, to be fair, may
>> include many lua projects), and often not even then, because even
>> trivial autoconf files are usually much simpler than the equivalent
>> shell-script.
>
> Would you consider LuaJIT to be a "trivial" case? It doesn't use
> anything but straight-up "make".

I've never looked at LuaJIT's build systems, so it's hard for me to say.

There are certainly "reasonably portable" packages out there that
depend only on make (e.g., git), but those that are complex enough
often simply end up essentially duplicating what autoconf does
themselves.  That's the authors choice, of course, but it's not a step
for the faint of heart, as it tends to make makefiles complex and
fragile.

> I'm going to have to agree: autoconf is an unnecessary extra step in
> software deployment on modern systems, and one that slows down build
> times for little tangible benefit.

In certain cases, that's true.  In others, it is just wrong.

It all depends on the nature of the software, on the
libraries/services it needs, and the goals of the author.  Software
that is "purely computational" (and so needs little in the way of
external libraries or services) can often be written portably enough
to avoid the need for configuration, although this can be hard if you
want to _actually_ be portable, even to a restricted range of systems
(like "typical linux systems", and especially if you include oddball
but popular cases like macosx).

My general development route is to start out with simple Makefiles,
and keep them as long as possible.  In cases where just make (with
maybe some helper shell scripts) are enough, this is nice.  But in
many cases, this simply doesn't prove to be adequate in the long run.

[and note that one of the best things about the autotools is not
actually autoconf, but automake, which allows far more concise and
readable/maintainable makefiles than doing the same thing in raw
make.]

So I don't think there's really any need for an argument:  if make
proves enough, then use it.  If it's not, then use something more.
It's OK to change somewhere down the line if the first choice doesn't
work out.  Leave ideological purity to the fanbois... :)

-miles

--
Guilt, n. The condition of one who is known to have committed an indiscretion,
as distinguished from the state of him who has covered his tracks.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Coda Highland
> My general development route is to start out with simple Makefiles,
> and keep them as long as possible.  In cases where just make (with
> maybe some helper shell scripts) are enough, this is nice.  But in
> many cases, this simply doesn't prove to be adequate in the long run.
>
> [and note that one of the best things about the autotools is not
> actually autoconf, but automake, which allows far more concise and
> readable/maintainable makefiles than doing the same thing in raw
> make.]
>
> So I don't think there's really any need for an argument:  if make
> proves enough, then use it.  If it's not, then use something more.
> It's OK to change somewhere down the line if the first choice doesn't
> work out.  Leave ideological purity to the fanbois... :)

This is the kind of pragmatic approach I like. :) Start as simple as
possible instead of overdoing it up front, and add more if you need
it.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Aleksey Cheusov
In reply to this post by Sam Roberts
Consider using mk-configure as a replacement for autotools.

http://sourceforge.net/projects/mk-configure
https://github.com/cheusov/mk-configure

It is a portable general purpose build automation system that has
support for Lua.
You can find simple examples under examples/hello_lua{,2,3}
directories on github.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

liam mail
In reply to this post by Sam Roberts
On 17 July 2012 01:32, Sam Roberts <[hidden email]> wrote:
> Btw, I also looked at premake, and its pretty much exactly what I
> don't want, a replacement for make, that controls all aspects of the
> build. Nice that its in lua, but no...

FYI and you are not alone in thinking this, but this is not what
Premake is. As the name would suggests it runs before make (or others)
and is a cross platform project generator ie it generates Visual
Studio solutions, Xcode projects, makefiles, CodeBlocks, CodeLite etc
much like CMake does yet using a sane Language :)

> that controls all aspects of the build
With the latest development version you can add blocks of code which
will be placed as is into a Makefile etc and you have been able to run
your own scripts for build events for a long time, ie it does not
always control all aspects.

Liam

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Sam Roberts
In reply to this post by Coda Highland
[hidden email] wrote:

>>> The better alternative to autoconf is usually nothing, IMO.

Clearly, I don't agree, or I wouldn't be looking for one :-)

This makefile approach is crap:  https://github.com/sam-github/pcap-lua

It only supports two platforms, but not well, and I have to copy the
boilerplate approach to all my projects, where they slowly
desynchronize.

On Mon, Jul 16, 2012 at 10:26 PM, Coda Highland <[hidden email]> wrote:
> Would you consider LuaJIT to be a "trivial" case? It doesn't use
> anything but straight-up "make".

Yes, I would. I just looked, and luajit appears to have only trivial
dependencies: a C library and gcc. Most of its 600+ lines of
src/Makefile is devoted to figuring out how to call gcc for the
platforms it supports.

I maintain libnet (but did not write it, or make its autoconf system),
and system networking APIs vary enormously, I would describe it
as non-trivial. auto* is mostly for testing existence of dependencies,
when the mere fact that you are compiling on a platform is not
sufficient to know if an optional dependency exists.

Also, if your platform support is wide, it can be better to declare
what you want from a system, then try to exhaustively list for every
supported system, whether you believe it does or does not have a
particular facility.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Sam Roberts
In reply to this post by Aleksey Cheusov
On Tue, Jul 17, 2012 at 3:49 AM, Aleksey Cheusov <[hidden email]> wrote:
> Consider using mk-configure as a replacement for autotools.

Thanks, Aleksey, I'll check it out.

Sam

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

William Ahern
In reply to this post by Sam Roberts
On Tue, Jul 17, 2012 at 11:25:27AM -0700, Sam Roberts wrote:
> [hidden email] wrote:
>
> >>> The better alternative to autoconf is usually nothing, IMO.
>
> Clearly, I don't agree, or I wouldn't be looking for one :-)
>
> This makefile approach is crap:  https://github.com/sam-github/pcap-lua

That's not too bad. Obvious issues are that one shouldn't put an explicit
"/" after $(DESTDIR), and install is not a POSIX utility. It requires GNU
Make, but that's fair.

> It only supports two platforms, but not well, and I have to copy the
> boilerplate approach to all my projects, where they slowly
> desynchronize.

You also have to write different code for each project. I don't see what the
issue is.

The search for the perfect automated build system is a fool's errand, IMHO.
Your best bets are either autoconf (if you know it and don't care about the
versioning nightmare) or standard make and unix utilities. That is, of
course, my own opinion.

Some day I'd like to write a makefile translator which can convert certain
non-portable macro and conditional constructs between the various make
flavors. But I'll never pretend that it would be preferable than autoconf or
plain make for general usage. There are two customers, myself and the users
of my code. I may be comfortable with one approach, but third parties
generally expect either autoconf or plain Make. Use anything else and their
ability to fix build bugs or contribute patches drops dramatically.

> On Mon, Jul 16, 2012 at 10:26 PM, Coda Highland <[hidden email]> wrote:
> > Would you consider LuaJIT to be a "trivial" case? It doesn't use
> > anything but straight-up "make".
>
> Yes, I would. I just looked, and luajit appears to have only trivial
> dependencies: a C library and gcc. Most of its 600+ lines of src/Makefile
> is devoted to figuring out how to call gcc for the platforms it supports.

And how many lines of autoconf'd M4 and shell code would be required to
introspect this, or to declare it as an option through the build?

You have to compare apples to apples. And even if using autoconf or
something else required fewer lines of code, you have to offset it against
the hassle.

> I maintain libnet (but did not write it, or make its autoconf system), and
> system networking APIs vary enormously, I would describe it as
> non-trivial. auto* is mostly for testing existence of dependencies, when
> the mere fact that you are compiling on a platform is not sufficient to
> know if an optional dependency exists.
>
> Also, if your platform support is wide, it can be better to declare what
> you want from a system, then try to exhaustively list for every supported
> system, whether you believe it does or does not have a particular
> facility.

I've written and maintained an asynchrounous sockets and stub/recursive DNS
library for several years. For cqueues I decided to make sure those source
files worked under Solaris, NetBSD, and FreeBSD (previously I only ever
wrote it for OS X, OpenBSD, and Linux). Lo-and-behold the entire thing
compiled just fine on all of those with very little effort. The only real
issue was my CPP-based byte ordering detection was wrong for my DNS packet
structure.

Supporting all of those platforms (including kqueue/epoll/completion ports)
in portable source code requires no support from the build system
whatsoever. The makefile's only job is to figure out how to invoke the
compiler and linker properly.

I see that libnet supports OSF/1 and Windows, and like I said before once
you step outside the modern world of POSIX things get really hairy. But in
those cases I _especially_ doubt that there'll be a satisfactory automated
build solution. Elbow grease and aspirin is about the only way to approach
it.


Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Xavier Wang
In reply to this post by Aleksey Cheusov
but it requires bmake, which is not available in Windows :(

I also hopes can have a Windows version of bmake very much, but no
lucky, so on windows, GNU make is the only choice

2012/7/17 Aleksey Cheusov <[hidden email]>:

> Consider using mk-configure as a replacement for autotools.
>
> http://sourceforge.net/projects/mk-configure
> https://github.com/cheusov/mk-configure
>
> It is a portable general purpose build automation system that has
> support for Lua.
> You can find simple examples under examples/hello_lua{,2,3}
> directories on github.
>

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Aleksey Cheusov
On Wed, Jul 18, 2012 at 3:17 AM, Xavier Wang <[hidden email]> wrote:
> but it requires bmake, which is not available in Windows :(

Sorry, what is Windows? :-P

> I also hopes can have a Windows version of bmake very much, but no
> lucky,

Seriously, bmake can be compiled on Cygwin and Interix.
So, it is definitely available on Windows.

> so on windows, GNU make is the only choice

No ;-)

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Aleksey Cheusov
In reply to this post by William Ahern
On Tue, Jul 17, 2012 at 11:15 PM, William Ahern
<[hidden email]> wrote:

> On Tue, Jul 17, 2012 at 11:25:27AM -0700, Sam Roberts wrote:
>> [hidden email] wrote:
>>
>> >>> The better alternative to autoconf is usually nothing, IMO.
>>
>> Clearly, I don't agree, or I wouldn't be looking for one :-)
>>
>> This makefile approach is crap:  https://github.com/sam-github/pcap-lua
>
> That's not too bad.

If it was written in mk-configure, i'd look like the following (not
tested, only idea is demonstrated).

----------------------------------------
LUA_MODULES = pcapx.lua # .lua module
LUA_CMODULE =  pcap # Lua module written in C (pcap.c)
SCRIPTS = pcap-recode pcap-dump pcap-split

WARNS = 4 # highest possible compiler's warning level

all: README.txt
README.txt: README.txt.in pcap.c
        cp README.txt.in $@
        luadoc pcap.c >> $@

test:
   ...
doc:
   ...

.include <mkc.mk>
----------------------------------------
That's it.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

steve donovan
In reply to this post by Aleksey Cheusov
On Wed, Jul 18, 2012 at 11:51 AM, Aleksey Cheusov <[hidden email]> wrote:
> Seriously, bmake can be compiled on Cygwin and Interix.
> So, it is definitely available on Windows.

True, it's amazing how close you (as a developer) can get Windows to
look like Unix.

But it places a big burden on ordinary people just wanting to build
the software, with the standard mingw download.

So there are three kinds of pain to be minimized:
  1 original developer
  2 anybody wishing to patch and modify
  3 users just wanting to build

Generally, we expect (1) to take some extra pain so that (3) is
happier. After all, we _do_ want software to be used ;)

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Aleksey Cheusov
On Wed, Jul 18, 2012 at 1:06 PM, steve donovan
<[hidden email]> wrote:
> On Wed, Jul 18, 2012 at 11:51 AM, Aleksey Cheusov <[hidden email]> wrote:
>> Seriously, bmake can be compiled on Cygwin and Interix.
>> So, it is definitely available on Windows.
>
> True, it's amazing how close you (as a developer) can get Windows to
> look like Unix.

In the middle 90th I was a Windows user, so, I can feel the pain.
But I believe that UNIX tools ported to Windows (cygwin and interix)
gives Windows developers A LOT of power. So, it makes sense for them
to learn UNIX tools once and use them for years. IMHO mingw is not relevant.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Aleksey Cheusov
In reply to this post by Aleksey Cheusov
> If it was written in mk-configure, i'd look like the following (not
> tested, only idea is demonstrated).

I overlooked one important fragment from pcap makefile. Analog in mk-configure
may look like the following.
...
CFLAGS_pcap != pcap --cflags
LDADD_pcap   != pcap -- libs
CFLAGS += ${CFLAGS_pcap}
LDADD += ${LDADD_pcap}
...

I introduced two new _pcap variables not because it's not possible to write
everything in two lines but because with _pcap variables it's easier for package
maintainer to overwrite the defaults.

P.S.
mk-configure supports pkg-config, so, if pcap library use it,
Makefile will look even easier.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

steve donovan
In reply to this post by Aleksey Cheusov
On Wed, Jul 18, 2012 at 12:15 PM, Aleksey Cheusov <[hidden email]> wrote:
> gives Windows developers A LOT of power. So, it makes sense for them
> to learn UNIX tools once and use them for years. IMHO mingw is not relevant.

Ah, but if I want Unix, I know where to find it ;)

Mingw is relevant because it's a straightforward way for people to get
a good working GCC on their computers, especially with the Dragon
distribution. 15Meg download, they have a C compiler.  But they won't
have anything more than GNU make, and that's often not enough. This is
why things like CMake are definitely relevant here, even though it
makes my eyes bleed.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

David Given
In reply to this post by Aleksey Cheusov
Aleksey Cheusov wrote:
[...]
> In the middle 90th I was a Windows user, so, I can feel the pain.
> But I believe that UNIX tools ported to Windows (cygwin and interix)
> gives Windows developers A LOT of power. So, it makes sense for them
> to learn UNIX tools once and use them for years. IMHO mingw is not relevant.

We recently switched our development system from Cygwin to Mingw because
Cygwin was becoming far too much of a PITA to use --- recent versions
get on *really* badly with having more than one version of Cygwin
installed at a time, or calling out to non-Cygwin command line tools
from Cygwin, or calling in to Cygwin command line tools from non Cygwin...

Mingw tries much less hard than Cygwin to be Unix-like, which makes it
much simpler and easier to understand, and vastly easier to deploy in a
turnkey environment which may need to coexist with random other tools
the user may have deployed. And the licensing is vastly, vastly easier
and cheaper.

(GNU make on Windows is still a dead loss, though; it can't cope with
targets containing colons, such as any Windows-style path...)

--
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car." --- Scott Adams




signature.asc (270 bytes) Download Attachment
123