* Alexander Neundorf [EMAIL PROTECTED] schrieb:
On Monday 16 June 2008 17:15:37 Enrico Weigelt wrote:
* Alexander Neundorf [EMAIL PROTECTED] schrieb:
CMake has a cache, where the values of variables are stored, e.g. if an
option is enabled or not, or where a library has been found (e.g.
* Adrian Bunk [EMAIL PROTECTED] schrieb:
Hi,
I won't to that w/ my TreeBuild. It is intentionally limited on
easily structured packages. People should either structure their
packages properly use something else ;-P
For simple packages autoconf+automake+libtool is already near at your
On Tuesday 17 June 2008 15:46:36 Enrico Weigelt wrote:
* Alexander Neundorf [EMAIL PROTECTED] schrieb:
On Monday 16 June 2008 17:15:37 Enrico Weigelt wrote:
* Alexander Neundorf [EMAIL PROTECTED] schrieb:
CMake has a cache, where the values of variables are stored, e.g. if
an option
On Saturday 14 June 2008 01:19:32 you wrote:
...
I still don't understand why all the scons, cmakes and jams out there
don't even try to provide the *standard* user interface everyone is used
to on a unix system.
For cmake:
CMake has a cache, where the values of variables are stored, e.g. if
On Friday 13 June 2008 16:51:19 Enrico Weigelt wrote:
...
That's why I prefer an purely descriptive paragidm (= subset of
delcarative, but practically no logic): a buildfile should only
describe the package's structure (eg.: i have some executable foo
which consists of source [...] and imports
On Monday 16 June 2008 01:12:41 Enrico Weigelt wrote:
* Robert Schwebel [EMAIL PROTECTED] schrieb:
Hi,
Instead of hacking around and inventing new things, you should have
spent your time for improving libtool ...
No, not with libtool.
I do not want to support that insane approach of
Enrico Weigelt wrote:
Most times I've seen those checks, they silently enable some
features, eg. if it looks for certain kernel devices. Definitively
the wrong way!
Agreed. Though, you do often have to check for headers etc.,
otherwise you won't have the definitions needed to work with those
On Mon, 2008-06-16 at 11:49 +0100, Jamie Lokier wrote:
But here's the thing: do you really want every package have code
calling every different variation on a system call, at run time, until
it finds one that works?
No. That functionality lives in libc, if you want it at all.
--
dwmw2
--
To
Enrico Weigelt wrote:
Reality is that Kconfig front end to autotools does work - as you've
proved. It's a good idea. :-)
Now, we just need an autoconf-alike frontend for Kconfig ;-)
I agree and would support:
./configure --menu
Invokes a configuration menu / wizard for
David Woodhouse wrote:
On Mon, 2008-06-16 at 11:49 +0100, Jamie Lokier wrote:
But here's the thing: do you really want every package have code
calling every different variation on a system call, at run time, until
it finds one that works?
No. That functionality lives in libc, if you want
On Mon, 2008-06-16 at 12:52 +0100, Jamie Lokier wrote:
E.g. Calls to pread should _not_ be implemented as lseek+read+lseek on
old kernels which don't have pread. That leads to race conditions and
corruption in some applications. (I think this has really occurred,
but I'm unable to find it
On Monday 16 June 2008 13:39:46 you wrote:
...
If you're going to rewrite Autotools using GNU Make, why not ask if
another tool would be better, perhaps a tool specially designed for
the job?
Go ahead.
The first part of going ahead is to brainstorm and find ideas and
likely
Alexander Neundorf wrote:
On Monday 16 June 2008 13:39:46 you wrote:
...
If you're going to rewrite Autotools using GNU Make, why not ask if
another tool would be better, perhaps a tool specially designed for
the job?
Go ahead.
The first part of going ahead is to brainstorm
* Alexander Neundorf [EMAIL PROTECTED] schrieb:
CMake has a cache, where the values of variables are stored, e.g. if an
option
is enabled or not, or where a library has been found (e.g.
JPEG_LIBRARY=/usr/local/lib/libjpeg.so).
The way to influence the behaviour of cmake is to change the
* Alexander Neundorf [EMAIL PROTECTED] schrieb:
That's why I prefer an purely descriptive paragidm (= subset of
delcarative, but practically no logic): a buildfile should only
describe the package's structure (eg.: i have some executable foo
which consists of source [...] and imports libs
On Mon, Jun 16, 2008 at 02:32:01PM +0100, Jamie Lokier wrote:
No, I'm talking about improving Autotools to handle some things better
than they do now. Passing the high hurdles required to become part of
Autotools - especially compatibility - is part of the goal.
If you look at the sh scripts
On Mon, Jun 16, 2008 at 11:28:36PM +0100, Jamie Lokier wrote:
Bernhard Fischer wrote:
On Mon, Jun 16, 2008 at 02:32:01PM +0100, Jamie Lokier wrote:
No, I'm talking about improving Autotools to handle some things better
than they do now. Passing the high hurdles required to become part
* Jamie Lokier [EMAIL PROTECTED] schrieb:
A trouble with that is some packages have hundreds of user-selectable
options - or even thousands. It is unfeasible to use --enable-foo
options for all of those when configuring then.
Well, not that much ;-o
But taking care of such feature switches
* Jamie Lokier [EMAIL PROTECTED] schrieb:
Media players with lots of optional formats and drivers are another.
(They also have considerable problems with their Autoconf in my
experience).
You probably mean their hand-written ./configure script, which is
intentionally incompatible w/ autoconf
On Friday 13 June 2008 03:29:52 Mike Frysinger wrote:
On Thu, Jun 12, 2008 at 9:25 PM, Rob Landley wrote:
He recently converted Battle for Wesnoth to use something called scons
as its build system,
Battle of Wesnoth is currently converted to both Scons and CMake, and in the
end they will
On Friday 13 June 2008 11:12:00 you wrote:
On Fri, 2008-06-13 at 11:06 +0200, Alexander Neundorf wrote:
Why on earth does someone need this explicitly during the build?
If you have portable software, all of that should be hidden in the code
and use sizeof(int).
From the developer of
On Thu, 12 Jun 2008, Robert P. J. Day wrote:
On Thu, 12 Jun 2008, Mike Frysinger wrote:
On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
If we just made people write portable code and proper Makefiles,
it would be less of an issue :)
people cant even write proper *native*
On Thu, Jun 12, 2008 at 6:12 PM, Robert P. J. Day [EMAIL PROTECTED] wrote:
...
meooowww! :-) but at the risk of dragging this even further
off-topic, i am *constantly* asked by people how to set up makefiles
for their software project, and what would be nice is a small
collection of examples
On Thu, Jun 12, 2008 at 3:02 PM, Mike Frysinger [EMAIL PROTECTED] wrote:
people cant even write proper *native* makefiles. mtd-utils for example ;).
What's wrong with it? I'll fix it.
is [EMAIL PROTECTED] not the place to post ? that's where
i sent the first fix yesterday ... not that i'm
On Thu, Jun 12, 2008 at 3:02 PM, Mike Frysinger [EMAIL PROTECTED] wrote:
people cant even write proper *native* makefiles. mtd-utils for example ;).
What's wrong with it? I'll fix it.
is [EMAIL PROTECTED] not the place to post ? that's where
i sent the first fix yesterday ... not that i'm
* Alexander Neundorf [EMAIL PROTECTED] schrieb:
In general, cross compiling is not hard. You just have to call the cross
toolchain, give it the correct parameters, search files in the right location
and ... make sure you don't test stuff by running programs.
Same with carefully written
* Alexander Neundorf [EMAIL PROTECTED] schrieb:
Well, IMO this makes it sound too easy.
If you write portable software, you have to do platform checks.
Basically they can be done by
-checking for the existence of files
-checking if something builds
-checking the output of running something
* Alexander Neundorf [EMAIL PROTECTED] schrieb:
E.g. in python there are tests which call functions and check
their result to see if we are currently on a platform where
that function is broken (I think there was such a test for
poll() and some other functions).
IMHO, that's broken sw
On Fri, Jun 13, 2008 at 05:11:04AM +0200, Sam Ravnborg wrote:
Tom has started a nice project which he named: quagmire.
See: http://code.google.com/p/quagmire/
From the website:
quagmire is intended to replace automake and libtool. Unlike these tools
it requires GNU make and is written
Bill Traynor wrote:
Do you wanna set some breakpoints and inspect variables in makefiles?
Have a look at a simple makefile debugger (written in make):
http://www.embedded.com/columns/technicalinsights/197003517?printable=true
The article above shows some macros you can add to your Makefile
On Thursday 12 June 2008 12:14:32 Bill Gatliff wrote:
Paul Mundt wrote:
Yes, that's the easy case. It's things like perl that are the corner
cases, and my objection comes from the fact that people think we ought to
not have the kernel depend on perl rather than just fixing the package
On Friday 13 June 2008 04:06:18 Alexander Neundorf wrote:
And the above are not really a big problem -
checking if something builds is no problem, this just works. Running
something is a problem, as in it doesn't just work (...because you cannot
run it).
Noticing 2 weeks after deployment
On Fri, Jun 13, 2008, Tim Bird wrote:
YMMV. I put some of the resources and info I found at:
http://elinux.org/Debugging_Makefiles
There is also remake, which is A patched GNU make with a debuger,
better tracing and error reporting (based on GNU make 3.80).
Development seems to have stopped,
Robert Schwebel wrote:
On Fri, Jun 13, 2008 at 08:30:52AM +0200, Alexander Neundorf wrote:
Battle of Wesnoth is currently converted to both Scons and CMake, and
in the end they will decide about the winner. (since Eric is good at
arguing I guess it will be scons).
The thing is that
On Fri, Jun 13, 2008 at 11:25:23PM +0100, Jamie Lokier wrote:
A trouble with that is some packages have hundreds of user-selectable
options - or even thousands.
I've not seen a package with thousands of user selectable options. It's
not even desirable, because the more options you have, the
Robert Schwebel wrote:
On Fri, Jun 13, 2008 at 11:25:23PM +0100, Jamie Lokier wrote:
A trouble with that is some packages have hundreds of user-selectable
options - or even thousands.
I've not seen a package with thousands of user selectable options. It's
not even desirable, because the
On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
Rob Landley wrote:
However, having one or more full-time engineers devoted to debugging
cross-compile issues is quite a high price to pay too. Moore's law really
doesn't help that
David Woodhouse wrote:
... fixing
them in the upstream packages (or in the autoconf system itself).
Once someone fixes the cross-compilation issues for a package, they usually
stay fixed, if the fixes are mainlined.
I don't think that's true, unfortunately. Autoconf makes it _easy_ to do
Guys:
If you opt to cross-compile, having to deal with those
sorts of things is the price you pay.
If the build system derives from autoconf, then a hacked-up config.cache (or
equivalent command-line args) often solves problems for me. Just give the cache
the answers that it would otherwise
39 matches
Mail list logo
