Helper files for autotools
Nicolas Alvarez
- compile: wrapper for compilers that don't understand -c -o.
- config.guess: gets the config name of the current platform (like
x86_64-unknown-linux-gnu).
- config.sub: not sure, it seems to do some extra checking on the platform
name config.guess returns.
- depcomp: compiles a program generating dependency list as side effect
- missing: stub for a few tools if they are missing when installing
- install-sh: install a program, script, or data file
- ltmain.sh: main file for libtool; I think it's used as template when
configure builds building the system-specific 'libtool'
Urias McCullough
I believe that config.guess, config.sub, install-sh and ltmain.sh can
all be installed when you run libtoolize --force --copy --install
Thus, keeping them in the repository is probably overkill, as this
line could probably be added to the _autosetup instead
This works on Haiku, anyhow, but please test that out on a couple
platforms before accepting what I say as fact :)
- Urias
Michael Tughan
system, but I do see glibtoolize in /usr/bin and it does have the
arguments you passed.
Michael Tughan
Michael's Programming
Urias McCullough
<michaelsp...@gmail.com> wrote:
>
> Where would libtoolize be found? I don't have that program on my OS X
> system, but I do see glibtoolize in /usr/bin and it does have the arguments
> you passed.
libtool (and libtoolize) is one of the GNU tools that is generally
used along with the other auto* tools:
http://www.gnu.org/software/libtool/
I'm guessing OS X renames it.
Michael Tughan
it is libtoolize renamed. Oddly enough, OS X has a newer version than
the newer Fedora 10 VM I have. That distro ships with libtoolize
1.5.26, which is 3-4 years old at this point, while the version
shipped with OS X Leopard is about a year old.
Michael Tughan
Michael's Programming
Urias McCullough
<michaelsp...@gmail.com> wrote:
>
> Yep, glibtoolize --version says "libtoolize (GNU libtool) 2.2.6", so it is
> libtoolize renamed. Oddly enough, OS X has a newer version than the newer
> Fedora 10 VM I have. That distro ships with libtoolize 1.5.26, which is 3-4
> years old at this point, while the version shipped with OS X Leopard is
> about a year old.
It's not an uncommon occurrence to find older autotools on modern
distros. One of the challenges we face with Haiku is that we have only
gotten our platform into the config.guess/config.sub in January 2008,
and we find most packages out there still use ANCIENT versions of
these files...
Haiku now uses libtool 2.2.6a as well.
Nicolas Alvarez
I would like to know what idiot thought it was a good idea to make
Ctrl-Enter immediately the message without any confirmation or way to stop
it.
As I was saying...
Just like with the configure file (built from configure.ac) and aclocal.m4
(made from files in m4), it may be a good idea not to have those helper
scripts in the repository. Instead, have _autosetup install them from the
system versions, using automake --add-missing.
Urias McCullough
<nicolas...@gmail.com> wrote:
> Just like with the configure file (built from configure.ac) and aclocal.m4
> (made from files in m4), it may be a good idea not to have those helper
> scripts in the repository. Instead, have _autosetup install them from the
> system versions, using automake --add-missing.
Yep, probably best.
BTW, I was told at some point that "automake --add-missing" just calls
upon libtoolize anyway - not sure if that's actually true.
- Urias
Nicolas Alvarez
Well, not all programs use libtool...
automake --add-missing surely works if the build machine doesn't have
libtool(ize) installed (but of course it won't install things like
ltmain.sh, would give an error if the app requires it).
Nicolas Alvarez
> Just like with the configure file (built from configure.ac) and aclocal.m4
> (made from files in m4), it may be a good idea not to have those helper
> scripts in the repository. Instead, have _autosetup install them from the
> system versions, using automake --add-missing.
Change done.