[Top][All Lists]

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

Re: Building prog first

From: Russell Shaw
Subject: Re: Building prog first
Date: Sun, 21 Mar 2010 23:14:22 +1100
User-agent: Mozilla-Thunderbird (X11/20091109)

Ralf Wildenhues wrote:
* Russell Shaw wrote on Sun, Mar 21, 2010 at 11:18:03AM CET:
Ralf Wildenhues wrote:
Use noinst_PROGRAMS instead of bin_PROGRAMS.  Be encouraged to read the
fine manual.
But it is somewhat big, and i had already searched through the online
one a lot first. It is no wonder it takes noobs so long to get productive.

I'm not sure how to help that.  If more documentation makes people less
likely to look at it, then what would you suggest in order to improve
upon the situation?  Is the documentation not structured well enough?
Does the "Autotools Introduction" chapter in the Automake manual not
help get a basic grasp?

I agree that the initial learning steps may not be easy for Automake,
but I don't see how to make Automake a lot easier without also ripping
out much of the functionality.  So turning that knob is fairly unlikely.

I was limping along for years learning autoconf/make in bits until this
tutorial came out

  Autotools: a practitioner's guide to Autoconf, Automake and Libtool

I realized a lot of useful things after that. The main thing that makes
it easy is that a real project is stepped through with lots of side discussions,
and high-level overviews put things in to perspective. I'd really like to have
a hard-copy book of that tutorial.

After that, i could understand the autoconf manual. I was on dos/windows
up to nearly yr2000 or so, so i had to learn unix programming, shell
programming, make-file programming, m4, how unix processes work etc,
to be able to look in generated Makefiles and "configure" and see from
that what errors i was making in and
Learning too many things simultaneously, but i know now.

BTW, execution of built programs like this makes your package unsuitable
for cross-compilation.  Just so you're aware of that.
Ok. I assume then that you can't build the tool for the host system while
the generated files are compiled for the target system?

First off, allow me to clarify the nomenclature as it is used in GNU
- the build system is the one you run configure and 'make all' on,
- the host system is the one that the programs which 'make all' normally
  generates and installs, will run on later,
- the target system does not exist.  Never.  Unless your package happens
  to be a compiler or linker (or similar).  Then, the target system is
  the one for which your installed compiler/linker will generate code

With that, your sentence above should have been
  Ok. I assume then that you can't build the tool for the build system while
  the generated files are compiled for the host system?

Not straight-forwardly, no.  Once you've got your basic package working
and cross compilation support is the only thing missing, please come
back and we'll explain.

Ok. Thanks for the help.

regards, Russell

reply via email to

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