Re: Building prog first

[Russell Shaw]

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.

Hi,
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

http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_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 configure.ac and automake.am.
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
> software:
> - 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
>   for.
>
> 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