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

Makefile.am question



Ralf could you edit this description into the file
doc/bsp_howto/makefiles.t
somewhere?  I think it is something that needs to be include in the
description
of BSP makefiles.

Thanks.

--joel

Ralf Corsepius wrote:
> 
> Am Fre, 2003-02-07 um 23.53 schrieb Till Straumann:
> > I'm in the process of brining my BSP in sync with the latest snapshot's
> > (auto)make files.
> >
> > I'm sure this has been asked before:
> >
> > What is the difference between TMPINSTALL_FILES and PREINSTALL_FILES?
> OK, I'll try to explain:
> 
> When building RTEMS, several files and directories get installed to
> various places within the build tree at different stages of the build
> process, during execution of different make targets.
> 
> These are
> make preinstall
> make all
> make install
> 
> "make preinstall" is a make target that is internally triggered _before_
> anything is _compiled_ ("preinstallation"). The files getting installed
> during "make preinstall" are contained in PREINSTALL_FILES, typically
> these are headers and very few other files (bsp_specs, linker scripts).
> 
> "make install" is the make target, which installs files to their final
> destination out of the build directories. These are handled by standard
> automake rules.
> 
> "make all" is them make target, which builds/compiles everything. Files
> supposed to get installed into the build directory _after_ _compilation_
> are contained in TMPINSTALL_FILES.
> 
> > The powerpc/shared/motorola_powerpc BSP who I am using as a reference
> > seems to make inconsistent
> Not unlikely.
> 
> > (maybe the logic behind it is just too
> > obscure for me to guess) use of both of them. Some Makefile.am use
> > TMPINSTALL_FILES some use PREINSTALL_FILES to get headers installed
> > into the build area... ??
> Basically, there is nothing wrong in using both.
> 
> Generally, PREINSTALL_FILES should be avoided whenever possible in favor
> TMPINSTALL_FILES, because preinstallation leads program authors to be
> careless about modular issues and can introduce severe modular problems.
> 
> Ralf

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985