Re: Maintainer friendly mode for autotools projects

[Ivan Levashew]

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

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

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