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?

Aleksey Cheusov
On Wed, Jul 18, 2012 at 1:48 PM, David Given <[hidden email]> wrote:
> (GNU make on Windows is still a dead loss, though; it can't cope with
> targets containing colons, such as any Windows-style path...)

There are miriads of problems in porting UNIX apps to Windows.
This is why in our company we use normal UNIX for developement
of Windows-based product.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Jay Carlson
In reply to this post by Sam Roberts
On Jul 16, 2012, at 8:32 PM, Sam Roberts wrote:

> I've been playing with it. I've had trouble finding a decent tcl
> syntax summary,

"Get used to disappointment."

Tcl is like the platonic essence of a programming language designed around string interpolation, in the same way Lua is for tables and Scheme is for cons cells. A lot of us have written various hacky little macro expansion languages; core Tcl is those done right. Tcl's major charm is that function arguments are not evaluated, making it easy to build special forms and little languages. So other than the core {}[]"$f" syntax, Tcl syntax is whatever you want it to be.

But as the saying goes, "there's no right way to do a wrong thing". Tcl may not be a mess like PHP, but pure and clean doesn't mean particularly ergonomic. Sure, everything is a string, but that's about as cool as everything being a void*; you still have to keep track of how a string should be interpreted. Is it a list? A command? A name of an object? A name of an array? Who's in charge of deleting its referent? You end up with all these second-order memory leaks, since there can be no GC which can know how to interpret strings as pointers.

All-string data structures can accidentally lead to algorithms with performance characterized as "superquadratic". And since everything's a string, Tcl is naturally missing closures, and Tk kinda needed them. Callbacks from UI events were just strings eval'd in the global context, with %x %y printf'd in.

The language STk was a decent Scheme connected to a patched Tk, and several other languages were maintaining essentially the same Tk patch: give widgets and callbacks a void* and a hook for GC for languages with values richer than strings. IIRC this patch was offered upstream but Osterhout was not interested in making life any easier for people who didn't want Tcl. In today's social environment, Tk would have forked, but that was considered far more rude in that era.

Tcl-the-distribution parted ways with Lua around the time Tcl reimplemented stdio; I think this was around 8.0. I do remember downgrading to Tcl 7.x because it was  significantly smaller when I built http://web.archive.org/web/20000821215129/http://vhl-tools.sourceforge.net/demo1.html . Later versions of Tk depended so heavily on Tcl libraries there was little point in trying to tease them apart.

Tcl did a lot of good in advancing the ideology of using scripting to build applications. It was the Lua of its era. But Lua is the Lua of this era.

Jay
Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

David Given
Jay Carlson wrote:
[...]
> Tcl is like the platonic essence of a programming language designed around string interpolation, in the same way Lua is for tables and Scheme is for cons cells. A lot of us have written various hacky little macro expansion languages; core Tcl is those done right. Tcl's major charm is that function arguments are not evaluated, making it easy to build special forms and little languages. So other than the core {}[]"$f" syntax, Tcl syntax is whatever you want it to be.

The Fossil DVCS/bug tracker/wiki/CMS (which I've been using, and is
really nice) uses a Tcl subset called TH1 as its default template
language. It's specifically a *template* language, designed to do simple
stuff in HTML files, rather than a fully-fledged scripting language, and
somewhat to my horror actually seems to do the job quite well...

The implementation is about 4000 lines of well-commented C, and the
programming manual is 26 pages:

http://www.sqliteconcepts.org/THManual.pdf

I can't say I *like* it, but I can appreciate the minimalism of the design.

--
┌─── 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
Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Luiz Henrique de Figueiredo
In reply to this post by Jay Carlson
> Tcl did a lot of good in advancing the ideology of using scripting to build applications. It was the Lua of its era. But Lua is the Lua of this era.

Very nicely put!

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

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

> 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 problems you point out above are a shining example of what the
issue is: and when I fix it, I have to hunt down all my projects and
fix it everywhere.

And actually, code reuse is a problem, too, I have a set of utilty
functions I cut-n-paste between projects, but that's outside of the
scope of the build tool.

> The search for the perfect automated build system is a fool's errand, IMHO.

I'm not looking for perfect, I'm looking for better, and to spend more
time writing src code, and less writing make/shell/awk.

>> 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?

If you think I'm criticizing Mike's approach or think he should be
using autotools, you misunderstand me: I think what Mike is doing is
fine, and I think it's trivial.

> I've written and maintained an asynchrounous sockets and stub/recursive DNS
> library for several years.

Yes, I've been looking at it (and udns and unbound) recently.

It consists of a single .c source file, and has no dependencies, or
even an install target!

It works fine, but as an example of why everybody should do it that
way, its not so convincing.

And I see you copy your hairy EXE_CC macro into two makefiles in the
same project.

> Supporting all of those platforms (including kqueue/epoll/completion ports)
> in portable source code requires no support from the build system
^^^^^^^^^^^^^^^^^^^^^^^^

Portable close-to-ansi-or-posix C src, like lua's, or your dns.c
requires only to know how to call cc, but those aren't the cases I'm
interested in. I'm interested in code that is not so trivially
portable.

> whatsoever. The makefile's only job is to figure out how to invoke the
> compiler and linker properly.

I see no sign that of support for epoll in the socket code in your
libdns/contrib/ directory.

Also, avoiding support in your build system for finding dependencies
by just including the dependencies in your project is certainly one
way to go, but its not what I want to do.

> I see that libnet supports OSF/1 and Windows, and like I said before once

But not with autotools, I don't think, it has seperate windows build
files. No idea if they even work, but I haven't gotten any bug
reports. I don't even pretend to test libnet on its myriad platforms.

Sam

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Eric Wing
In reply to this post by Sam Roberts
> 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...

I dropped autotools many years ago out of frustration. I found that
autotools did very little to help me (the project writer) to find and
detect which dependencies are available and let me do things
accordingly and that burden was on me to write more m4 scripts and
such. Also, I found the use of libtool by the tool chain to be
excruciatingly slow for large/complex projects.

Also, as others point out, autotools isn't very friendly to
environments that are not built around it (i.e. Windows) so it didn't
really do anything useful for us. Also of note, Apple no longer ships
GNU/GPL based tools with Xcode's command line tools.


I ended up with CMake a long while back. While far from perfect, I
think their overall approach/philosophy is sound. Instead of trying to
micromanage and reinvent the entire build tool chain, CMake is a
meta-build generator that constructs native projects (e.g. Makefiles,
Visual Studio projects, Xcode projects, Eclipse workspaces). This
empowers developers to use the tools they are familiar/comfortable
with.

I did a video introduction on this awhile back to demonstrate how
Makefile users, Eclipse users, Xcode users, and Visual Studio users
would all use a common project under CMake:
http://www.youtube.com/watch?v=CLvZTyji_Uw

My biggest gripe is the CMake language. I still have dreams of
resurrecting/finishing the Lua bindings to CMake some day, but its not
something I have time for in the foreseeable future.

For stock Lua, I know there are multiple CMakeLists.txt descriptions
for Lua. I wrote one myself (emphasizing/embracing proper Apple/Mac
conventions which requires some additional code, plus proposing a way
to coordinate independent projects with a simple unifying CMake
script). The repo links can be found here:
http://playcontrol.net/ewing/jibberjabber/mercurial_subrepos_a_past_e.html

-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Doug
Idly, I agree with all your points.

Gad, it'd be so amazing to be able to write my cmake scripts in lua
instead of the retard cmake syntax.

Just imagine, a cmake:execute_process(...) and
cmake:add_library(sources) instead of ADD_LIBRARY("${SOURCES}").

*day dreams*

~
Doug.

On Thu, Jul 19, 2012 at 3:10 AM, Eric Wing <[hidden email]> wrote:

>> 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...
>
> I dropped autotools many years ago out of frustration. I found that
> autotools did very little to help me (the project writer) to find and
> detect which dependencies are available and let me do things
> accordingly and that burden was on me to write more m4 scripts and
> such. Also, I found the use of libtool by the tool chain to be
> excruciatingly slow for large/complex projects.
>
> Also, as others point out, autotools isn't very friendly to
> environments that are not built around it (i.e. Windows) so it didn't
> really do anything useful for us. Also of note, Apple no longer ships
> GNU/GPL based tools with Xcode's command line tools.
>
>
> I ended up with CMake a long while back. While far from perfect, I
> think their overall approach/philosophy is sound. Instead of trying to
> micromanage and reinvent the entire build tool chain, CMake is a
> meta-build generator that constructs native projects (e.g. Makefiles,
> Visual Studio projects, Xcode projects, Eclipse workspaces). This
> empowers developers to use the tools they are familiar/comfortable
> with.
>
> I did a video introduction on this awhile back to demonstrate how
> Makefile users, Eclipse users, Xcode users, and Visual Studio users
> would all use a common project under CMake:
> http://www.youtube.com/watch?v=CLvZTyji_Uw
>
> My biggest gripe is the CMake language. I still have dreams of
> resurrecting/finishing the Lua bindings to CMake some day, but its not
> something I have time for in the foreseeable future.
>
> For stock Lua, I know there are multiple CMakeLists.txt descriptions
> for Lua. I wrote one myself (emphasizing/embracing proper Apple/Mac
> conventions which requires some additional code, plus proposing a way
> to coordinate independent projects with a simple unifying CMake
> script). The repo links can be found here:
> http://playcontrol.net/ewing/jibberjabber/mercurial_subrepos_a_past_e.html
>
> -Eric
> --
> Beginning iPhone Games Development
> http://playcontrol.net/iphonegamebook/
>

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Doug
In reply to this post by Aleksey Cheusov
-_- as a developer force to support windows apps built on mingw,
please don't say that.
If lua ever stopped being buildable for that target it'd be a nightmare.

~
Doug.

On Wed, Jul 18, 2012 at 6:15 PM, Aleksey Cheusov <[hidden email]> wrote:

> 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?

William Ahern
In reply to this post by Sam Roberts
On Wed, Jul 18, 2012 at 11:49:15AM -0700, Sam Roberts wrote:
> > Supporting all of those platforms (including kqueue/epoll/completion ports)
> > in portable source code requires no support from the build system
> ^^^^^^^^^^^^^^^^^^^^^^^^
>
> Portable close-to-ansi-or-posix C src, like lua's, or your dns.c
> requires only to know how to call cc, but those aren't the cases I'm
> interested in. I'm interested in code that is not so trivially
> portable.

Therein lies much of the problem. Portability is often an after thought. For
example, people say, "I want do to XYZ". So they implement XYZ in Linux.
Then they tack on support for FreeBSD. Windows. Etc. It becomes a mess, even
if at the outset they intended to make it portable.

If they stood back and thought carefully about portability ahead of time,
they may have structured their project differently; approached the
implementation from a different direction; move a particular element up or
down the abstraction stack.

Instead, they wind up with a mess of problems and lean on the build system
to help solve them.

Example: asynchronous I/O. Windows and Unix use completely different
approaches. The primitives they expose, and the assumptions they make, are
completely at odds. Something like libevent is too low on that stack, which
makes it needlessly messy and confusing to use. libevent ends up with the
worst of both worlds and none of the redeeming qualities of either. And it's
Windows build is perennially broke, just like for most FOSS projects which
try to provide seamless POSIX and Windows support.

Out-of-the-box portability across disparate systems is rarely worth the time
and effort; it's a tarpit. Most projects which try it fail. Ultimately
support still requires user or developer intervention, so the effort in
automation was a complete wash. Time is better spent making it easier to
port--that is, as an active exercise.

> > whatsoever. The makefile's only job is to figure out how to invoke the
> > compiler and linker properly.
>
> I see no sign that of support for epoll in the socket code in your
> libdns/contrib/ directory.

It's in the cqueues/ projects, about two hundred lines in the middle of the
Lua module cqueues.c.

> Also, avoiding support in your build system for finding dependencies
> by just including the dependencies in your project is certainly one
> way to go, but its not what I want to do.

Most of my code gets put into appliances and cloud environments. It gets
used _because_ it's easy to integrate into a project and tweak and modify.
And most of all, because it lacks dependencies. Dependencies cause nothing
but headaches. That's why so many commercial products have so many
vulnerabilities; updating dependencies is a nightmare. Merely making
something into a library does not solve that problem, and in fact can make
it worse because it turns the library into more of a black box, making it
seem more risky to swap out for a newer version. And if multiple components
depend on the same library, it's an all-or-nothing proposition, making it
less likely it'll get updated regularly. Adding library versioning into the
mix creates even more uncertainty; or at best puts you back to square 1, but
with a plethora of confusing libraries and headers.

The key characteristic that makes developer's lives easier is simplicity and
isolation. That's different than a black box. A black box says, "Do not
enter." Isolation means, "Play with me, you're not going to break anything."

I'm not saying installed libraries are bad. I'm just saying they're over
used, and used prematurely. Something that works well for libc or openssl is
not necessarily best for project foo.

A great counterexample is Lua. I really wish Lua had a more dependable
installation where Lua 5.1 and Lua 5.2 could sit side-by-side. But Lua
succeeded partly because it didn't try to solve this early on. It's only
after becoming successful that this was something that needed (needs) to be
addressed.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Tony Finch
In reply to this post by William Ahern
William Ahern <[hidden email]> wrote:
> On Tue, Jul 17, 2012 at 11:25:27AM -0700, Sam Roberts wrote:

> > 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.

One of the things that annoys me about autoconf-style configuration is the
idea that the same build commands can build a package with different
features because of some environmental change. I prefer builds that are
reproducible, and that fail rather than quietly disabling functionality.

> The only real issue was my CPP-based byte ordering detection was wrong
> for my DNS packet structure.

http://commandcenter.blogspot.co.uk/2012/04/byte-order-fallacy.html

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Forties: Northerly 5 to 7, decreasing 4 in west. Moderate or rough. Rain then
showers. Good, occasionally moderate.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Axel Kittenberger
In reply to this post by steve donovan
> 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.

Did we had the same discussion a few months ago? I'll repeat my point
back then  ;-) Yes, from a /user/ perspective who downloads and builds
the application/library this is true. But I really like to hear the
opinion of a distros package manager. From them the noise is useful,
and from what I get they love autoconf built packages, since it allows
them to all the funky stuff they need out of the box like virtual
root. In that case the /user/ as in user will just click the package
from the package manager of his/her choice and never be into any of
the details of building it.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Luiz Henrique de Figueiredo
> Did we had the same discussion a few months ago?

Probably. Perhaps we can then close this discussion, which is getting OT.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Craig Barnes
In reply to this post by Axel Kittenberger
On 19 July 2012 22:15, Axel Kittenberger <[hidden email]> wrote:

>
> > 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.
>
> Did we had the same discussion a few months ago? I'll repeat my point
> back then  ;-) Yes, from a /user/ perspective who downloads and builds
> the application/library this is true. But I really like to hear the
> opinion of a distros package manager. From them the noise is useful,
> and from what I get they love autoconf built packages, since it allows
> them to all the funky stuff they need out of the box like virtual
> root. In that case the /user/ as in user will just click the package
> from the package manager of his/her choice and never be into any of
> the details of building it.
>

Autoconf does nothing for me as a packager, except make the build
process as opaque and indirect as possible. Passing flags to an
ifdef'd Makefile build is much nicer and easier to understand than any
autotools build.

Even the Nginx build system is more straight forward than autotools
and they use a huge pile of shell scripts.

Take a look at this:

http://pkgs.fedoraproject.org/gitweb/?p=lua.git;a=blob;f=lua-5.1.4-autotoolize.patch;h=afcb3fbeea3d4542359402803c5f096270253dae;hb=HEAD

Yup, Fedora's "autotoolize" patch for Lua 5.1.4 is 40,000 lines! More
than double the size of Lua itself. That for me is just too much to
stomach, regardless of the supposed "virtues" of autotools.

I also recently saw someone submit an "autotoolize" patch for a
project I work on. The "project" is a 500 line text-processing
utility. The autotoolize patch was about 10,000 lines.

autotools is a cult!

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Andres Perera
On Thu, Jul 19, 2012 at 5:54 PM, Craig Barnes <[hidden email]> wrote:
>
> Autoconf does nothing for me as a packager, except make the build
> process as opaque and indirect as possible. Passing flags to an
> ifdef'd Makefile build is much nicer and easier to understand than any
> autotools build.

by ifdef'd makefile you mean gmake or pmake dependent, or actually
processing it with cpp? could you show me an example of such a
makefile that covers the amount of architectures autoconf does? i
would like to see how it manages to provide compatibility without
indirection and complexity

>
> Even the Nginx build system is more straight forward than autotools
> and they use a huge pile of shell scripts.

well, what runtime do you use to probe the system for features other
than shell? this ties in to the previous question: show me a project
with as many targets so that i can objectively compare the two. i
would assume that's the expected course of action before deciding one
approach is inferior -- not withstanding holding the opinion that some
autoconf targets aren't relevant

>
> Take a look at this:
>
> http://pkgs.fedoraproject.org/gitweb/?p=lua.git;a=blob;f=lua-5.1.4-autotoolize.patch;h=afcb3fbeea3d4542359402803c5f096270253dae;hb=HEAD
>
> Yup, Fedora's "autotoolize" patch for Lua 5.1.4 is 40,000 lines! More
> than double the size of Lua itself. That for me is just too much to
> stomach, regardless of the supposed "virtues" of autotools.

in those 40,000 lines you also counted autogen.sh, and other scripts
that aren't tailored for each autoconf deployment -- they are either
generated or duplicated amongst projects. have you ever maintained a
project that uses autoconf? i ask because you're showing your
unfamiliarity by not discerning between "object" and "source"

>
> I also recently saw someone submit an "autotoolize" patch for a
> project I work on. The "project" is a 500 line text-processing
> utility. The autotoolize patch was about 10,000 lines.
>
> autotools is a cult!

i have no answer for this last line because you've completely dropped
any illusion of having technical merit to your critique

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Craig Barnes
On 20 July 2012 00:28, Andres Perera <[hidden email]> wrote:
>by ifdef'd makefile you mean gmake or pmake dependent, or actually
>processing it with cpp? could you show me an example of such a
>makefile that covers the amount of architectures autoconf does? i
>would like to see how it manages to provide compatibility without
>indirection and complexity

I was just giving a packager's perspective in relation to the previous
post. I don't claim to be an autotools expert by any means.

Tools are supposed to be helpful and usable are they not? Project
maintainers are not the only "users" of autotools. Other people have
to endure them too. Despite the effort to make autotools "just work" -
that frequently isn't the case.

I'm not attempting to discuss the technical merits or alternatives as
a maintainer - just giving a perspective as a downstream user - which
I think was made clear by my post and by the post I was replying to.

The last sentence was a bit trollish. I apologize for that.

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Dimiter 'malkia' Stanev
In reply to this post by Tony Finch
+1 to this.

I still don't get how autoconf works with cross compiling... Does it
actually?

Ideally it should create small test executables and run them on the
target platform... I doubt it's doing that...

On 7/19/2012 8:13 AM, Tony Finch wrote:

> William Ahern <[hidden email]> wrote:
>> On Tue, Jul 17, 2012 at 11:25:27AM -0700, Sam Roberts wrote:
>
>>> 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.
>
> One of the things that annoys me about autoconf-style configuration is the
> idea that the same build commands can build a package with different
> features because of some environmental change. I prefer builds that are
> reproducible, and that fail rather than quietly disabling functionality.
>
>> The only real issue was my CPP-based byte ordering detection was wrong
>> for my DNS packet structure.
>
> http://commandcenter.blogspot.co.uk/2012/04/byte-order-fallacy.html
>
> Tony.
>

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Coda Highland
On Thu, Jul 19, 2012 at 6:18 PM, Dimiter 'malkia' Stanev
<[hidden email]> wrote:
> +1 to this.
>
> I still don't get how autoconf works with cross compiling... Does it
> actually?
>
> Ideally it should create small test executables and run them on the target
> platform... I doubt it's doing that...

That's one reason I like using Scratchbox for cross-compiling. CPU
transparency via qemu is a marvelous thing and it can even
cross-compile stuff that doesn't normally cross-compile.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Dimiter 'malkia' Stanev
But then, there are platforms where that's not very possible - like much
of the video game consoles - there you can have only one process running
at the time.

On 7/19/2012 7:58 PM, Coda Highland wrote:

> On Thu, Jul 19, 2012 at 6:18 PM, Dimiter 'malkia' Stanev
> <[hidden email]> wrote:
>> +1 to this.
>>
>> I still don't get how autoconf works with cross compiling... Does it
>> actually?
>>
>> Ideally it should create small test executables and run them on the target
>> platform... I doubt it's doing that...
>
> That's one reason I like using Scratchbox for cross-compiling. CPU
> transparency via qemu is a marvelous thing and it can even
> cross-compile stuff that doesn't normally cross-compile.
>
> /s/ Adam
>
>

Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Jay Carlson
In reply to this post by Dimiter 'malkia' Stanev
[apologies for carrying this thread on, but speaking as a frequent cross-compiler and former distro maker, I think the ways autoconf actually assists cross-compilation are not intuitive]

On Jul 19, 2012, at 9:18 PM, Dimiter 'malkia' Stanev wrote:

> I still don't get how autoconf works with cross compiling... Does it actually?

Yes. It was easier to cross-compile autoconfiscated packages than anything else in the ~2001 timeframe, and autoconf has improved since then. The real disasters were things like perl's config script.

> Ideally it should create small test executables and run them on the target platform... I doubt it's doing that...

It can't do that when cross-compiling. However, run-time behavior comes up less often than you'd think. The presence of an #include or #define is a feature of the cross-compiler, not the target. This can be tested at compile time: does "mipsel-linux-gcc -c foo.c" succeed and produce a foo.o? The presence of a symbol, or which library is needed for a symbol, can be tested at link time.

Back in ~2001, the most common problem was questions like sizeof(int), which I thought was only knowable at run-time.[1] For features like that, it was convenient to preseed autoconf with a central config.cache with hand-written platform answers once--more convenient than manually patching handwritten makefiles for each package.

I wrote in http://lua-users.org/lists/lua-l/2011-11/msg00479.html :

> In a traditional self-hosted build process you can write a program
> that prints the sizeof all the types you care about and then generate
> C code based on that. But in cross-compilation environments, you may
> not have the ability to run code you compile. At some point autoconf
> gained the ability to deduce compile-time constants at by...declaring
> an array of size 1-2*!(expr). If expr is false, the size of the array
> is -1, and the compile fails. autoconf then does a *BINARY SEARCH* of
> the integers for the value....


Jay
 
[1]: Yeah, "testing for broken select() implementation" is not going to work. Sometimes just knowing the target is Linux is good enough for configure to skip those. In more extreme cases you can break out of the config script and hand-run the executable on the target, but I don't remember doing that much.
Reply | Threaded
Open this post in threaded view
|

Re: autotools alternatives, is anybody using autosetup?

Coda Highland
In reply to this post by Dimiter 'malkia' Stanev
On Thu, Jul 19, 2012 at 8:12 PM, Dimiter 'malkia' Stanev
<[hidden email]> wrote:
> But then, there are platforms where that's not very possible - like much of
> the video game consoles - there you can have only one process running at the
> time.

Well, certainly so, but I'm talking about POSIX platforms -- and even
so, some of those console platforms may have a suitable emulator in
the SDK if you mess with enough.

(Why are you top-posting? I thought you knew better.)

/s/ Adam

123