Build issue

[Gedare Bloom]

On Sat, May 12, 2012 at 1:57 AM, Ralf Corsepius
<ralf.corsepius at rtems.org> wrote:
> On 05/12/2012 02:41 AM, Claus, Ric wrote:
>>
>> In developing my BSPs, I am periodically re-confused by my changes not
>> "taking".  This seems to bite me with .h files and not .c files, although I
>> wouldn't claim that it is limited to .h files.  It is not resolved by any
>> number of ./bootstrap -c; ./bootstrap or ./bootstrap -p cycles in the source
>> tree, nor any ../src/configure commands in the build tree.  The only thing
>> I've found to remedy the situation is to blow away the build tree and
>> recreate it, then do the 'configure' and 'make all' steps again.  Copying
>> the affected source files by hand to the build tree also works, but seems
>> somewhat unorthodox.
>
>
> I do not understand which issues you are having.
>
Welcome to the joy of RTEMS + Autotools.

Since I know that Ric is doing port/bsp development in the past my
guess is this problem is with adding new code into RTEMS as opposed to
compiling an application against a released/working RTEMS. (This kind
of question is better targetted toward rtems-devel since it involves
hacking on rtems itself :))

>
>>
>> What is the standard operating procedure for this situation?  Is this considered a bug for which I should submit a PR?
>>
>
This is pretty close to SOP. I consider it a bug. Most core devs are
aware of this issue and "deal with it". The fix is a combination of
things, part of which Ralf addressed. The autotools approach seems to
have gone down a long and windy road in RTEMS and although it works
there are seemingly fundamental issues with it.

>> For what it's worth, I'm working with a freshly pulled master copy of the
>> git repository, the BSPs are PowerPC based and my configure step looks like:
>>
>> ../src/configure --target=powerpc-rtems4.11 --enable-posix
>> --enable-networking --enable-rdbg --enable-cxx --enable-maintainer-mode
>> --enable-rtemsbsp="virtex4 virtex5" --prefix=$TARGET_DIR
>
> Add --enable-maintainer-mode to this line.
>
Yep.

> Unless you are changing the structure of the source tree, this will
> automatically update all "bootstrap"-generated sources, if necessary
>
I believe he is making changes to the directory tree so he does need
to re-run bootstrap. Anyone who does BSP development has to deal with
bootstrap / automake issues.

>
>> On another topic, is there any way to limit what bootstrap operates on?
>
> Firstly, running bootstrap from the toplevel is only necessary once, after
> fresh checkout.
>
> Afterwards. if you have maintainer-mode enabled, there should not be any
> need for running bootstrap
>
Except when you add new files / modify configure.ac/Makefile.am files
you need to re-run bootstrap at the closest level to your modified
Makefile.am/configure.ac that contains a configure.ac file.

So for example if you add a .c file into say cpukit/score/src then the
file needs to be added to cpukit/score/Makefile.am and then you need
to re-run bootstrap from cpukit because that is the closest parent
directory with a configure.ac in it. For BSPs usually you just have to
deal with the libbsp/CPU/BSP directory.

In order to run bootstrap from there I use a shell variable that
points to my RTEMS root directory ($r) so that I can just ...
]  cd cpukit
]  $r/bootstrap

Ralf gave a similar example with ${RTEMS_HOME}. By the way the
bootstrap will work even if the shell variable points to a different
RTEMS source tree than yours (so you can work with multiple checkouts
but use the same bootstrap script regardless of the checkout).

When you add .h files that need to be installed (i.e. they will be
accessed by .c files searching for <rtems/someinclude.h> as opposed to
"someinclude.h") then you need to furthermore add the header into
include_..._HEADERS in the Makefile.am and run bootstrap -p from the
directory with the Makefile.am (you can just do bootstrap -p directly
there to regen the preinstall.am, though you can also do it at any
other parent directory as well). Then when preinstall.am is
regenerated you have to re-run bootstrap from some ancestor directory
containing configure.ac.

>
>>  Since it takes quite a while to complete and most of the BSPs are of no
>> interest to me, I would like to avoid bootstrapping them.
>
>
> You can selectively run bootstrap from sub-trees of the source tree.
>
> I.e. if you added a new files to c/src/lib/libbsp/<target>/<bsp>/ and have
> edited c/src/lib/libbsp/<target>/<bsp>/Makefile.am,
> you can
> cd ${RTEMS_HOME}/c/src/lib/libbsp/<target>/<bsp>/
> ${RTEMS_HOME}/bootstrap
>
> When building this <bsp> from this sourcetree with maintainer-mode enabled,
> rerunning make will automatically do this for you in most cases.
>
I don't believe make will re-run bootstrap when it detects
modifications in Makefile.am even with maintainer-mode on, but I might
be mistaken. I've never observed it do that for me though.  It will
pull in the modified Makefile.in if I re-run bootstrap myself though.
Without maintainer-mode on make will not even pull in modified
Makefile.in files, and you will have to wipe your build tree and
re-build from ../rtems/configure ....

> One final advise: Do not switch git-branches in git checkouts.
>  As git does not preserve timestamps, while make and the autotools are
> relying on timesstamps, this will break time-stamps on generated files and
> eventually result in havoc - You a toplevel bootstrap with each "git branch
> checkout".
>
>  To avoid this, my advise is to use multiple checkouts instead.
>
I haven't had problems with switching branches (at least not yet).
Most of the bootstrap-generated files are ignored by git anyways so I
don't see that branching should be a problem. Is this problem
something you have observed Ralf?

-Gedare

> Ralf
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users