[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Maintainer friendly mode for autotools projects

From: Ivan Levashew
Subject: Re: Maintainer friendly mode for autotools projects
Date: Mon, 16 Feb 2009 01:16:50 +0600
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ru; rv: Gecko/20081209 Thunderbird/ ThunderBrowse/ Mnenhy/

Steffen Dettmer wrote:

I'm not sure how it looks in your context, but I think usually
autoconf expects to be able to create a binary which usually
requires at least some libc.

Or are you compiling a libc itself?

No, not libc.

How should the knowledge base (I assume it would be some
delivered file) know what libraries a user has and wants to use?

I'm targetting Mac OS X in the first order. Here we have SDKs. SDK is an image of target system's root: SDK has System, Library, usr/lib and usr/include directories with headers and stripped libraries that are present on target system. Stripped libraries contain no code/data, just symbols. The only variation in this scheme is that user can have X11 not installed. The library is either present in SDK or being bundled with application. Even in case it's present in SDK, I might prefer to rebuild it and bundle with my app. ncurses was broken out-of-box, and I've got it fixed on my platform. However, I can't require users to do the same. If I want ncurses to be working fine, I need to bundle it with my app. If I want Perl to support locales properly, I need to bundle it with my app. Applications are easy to install on Mac OS X at cost of their size.

Crosscompiling, relocatability -- this all is an everyday reality here and is cause why there are so few properly ported open source applications on Mac OS X. Step left, step right -- and application you need is abscent. Gimp is ported, Dia is not. I have started trying to port Dia a year ago or so.

In abscense of such kb, there should be an option to generate
all the measurement scripts so that I could send them to
testers. Also, there must be an option to populate KB out of
measurement results. Whether the feature is supported
everywhere, nowhere or its support varies.

I think the idea of autoconf is to check whether a feature is
supported or not. When you have a test checking whether ANSI C /
ISO C headers are available it should work in any case on a
correctly configured system (well, as long as no /lib/cpp
fallback is performed ;)).
Unfortunately, for cross compiling possibilities because usually
test binaries cannot be run.

Well, I'm not sure if the assumption that a binary can be linked
(which must be true for cross compiling checks) is always

It will be correct for me. I'm not targetting embedded. Mac OS X, Interix, MinGW.

There is also a thread here about running cross compiling
binaries. I think, personally, if (as suggested in the thread) a
binary can simply run by running it, it should not be called

Here, on Intel Mac OS X I can run PowerPC with no problem. I can even not notice that it was PowerPC. I didn't know that gcc-3.3 produces PowerPC binaries, for example. PowerPC Duke Nukem 3D runs pretty fine.

I use this feature currently to build PowerPC versions without cross compile mode. But I'm not quite satisfied with it. My collegues on PowerPC Mac OS X are unable to do Intel builds as easy as I'm doing PowerPC ones.

I have no clue how to use simulators, like
additionally specifying some "wrappers" to be used for running
(like prefixing with "armsd $ARMSD_OPTS" or alike) and if it is
possible to have a slightly different setup [for instance, I need
to link with a special libc to be able to use armsd]).

Provided that you can extract tests, you can do anything with them. Run on emulator, on another machine, wherever.

I think for builing source and binary packages, a clean release
build environment is neccesary.

For binary packages it is easy: on this environment there must be
not library installed that the target host does not have. Some
virtual machine (vmware or alike) are fine for that I think.

Mac OS X in VMWare?.. no.

For source packages supporting several platforms and
configurations `reliable' IMHO is not possible, because for
testing (before each release containing any change) you would
need to have all combinations of environments.

What do you mean by testing here? Testing details of environment or testing the whole built program?

Details of environment are not gonna change.

If you want to get to the top, you have to start at the bottom

reply via email to

[Prev in Thread] Current Thread [Next in Thread]