* 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
Enrico == Enrico Weigelt [EMAIL PROTECTED] writes:
Hi,
Enrico * Bernd Petrovitsch [EMAIL PROTECTED] schrieb:
Recent pkg-config supports sysroot.
FC-6 has only 0.21.
Notice that sysroot is broken in 0.23 (it removes everything else than
-I / -L words). Patches have been posted to the
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
On Fre, 2008-06-13 at 20:51 +0200, 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
On Sam, 2008-06-14 at 01:07 +0100, Jamie Lokier wrote:
[...]
You said about too many user-selectable options. Many large packages
These are IME not a problem if they have somewhat sensible defaults.
_check_ for many installed libraries. Get them wrong, and you have
the same problems of
On Monday 16 June 2008 10:28:30 Bernd Petrovitsch wrote:
On Mon, 2008-06-16 at 10:02 +0200, Alexander Neundorf wrote:
[...]
Seriously, why is a wrapper for the compiler/linker required AT ALL if
the calls to these tools are made from _generated_ files ?
AFAIU the motivation of libtool to
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
Bernd Petrovitsch wrote:
_check_ for many installed libraries. Get them wrong, and you have
the same problems of untested combinations.
As long as I can specify that libfoo support must be compiled in (and
thus libfoo must be present) and the tools throw an error if it doesn't
find it, I
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
On Mon, 2008-06-16 at 12:17 +0100, Jamie Lokier wrote:
Bernd Petrovitsch wrote:
_check_ for many installed libraries. Get them wrong, and you have
the same problems of untested combinations.
As long as I can specify that libfoo support must be compiled in (and
thus libfoo must be
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
* Peter Korsgaard [EMAIL PROTECTED] schrieb:
Hi,
Notice that sysroot is broken in 0.23 (it removes everything else than
-I / -L words). Patches have been posted to the pkgconfig list several
times.
ugh, why didn't they just apply my patch which only appends
$sysroot to the pathes ?
* 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
Bernd Petrovitsch wrote:
Actually the size of ints (or any other type) can be easily deduced
without running a (for the target) compiled binary:
- compile the binary (for the target) with an initialized variable with
that value.
- use cross nm (or a similar tool) to read it from there.
Or
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 Fre, 2008-06-13 at 14:17 +0100, Jamie Lokier wrote:
Bernd Petrovitsch wrote:
Actually the size of ints (or any other type) can be easily deduced
without running a (for the target) compiled binary:
- compile the binary (for the target) with an initialized variable with
that value.
-
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
Enrico Weigelt wrote:
But: the question is whether you'll need such a test at all
or if just using sizeof() at the right place won't do the trick ;-P
It's best to do that if you can, and nearly always possible. There
are a few coding techniques - especially performance sensitive - where
that's
* 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 Fre, 2008-06-13 at 17:16 +0200, Enrico Weigelt wrote:
* Bernd Petrovitsch [EMAIL PROTECTED] schrieb:
Basically yes. But if you have a big number of packages (or a huge
package)
which you didn't write yourself, there will be tests which run
executables.
Figuring out what
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
50 matches
Mail list logo