Build issue

Sat May 12 17:38:22 UTC 2012

On Sat, May 12, 2012 at 12:08 PM, Gedare Bloom <gedare at rtems.org> wrote:
> 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.
>
I would like to clarify that I consider these problems bugs in how we
are using autotools. I do not know if the problems are fundamental to
autotools themselves or just with how we use them.

There is another little quirky issue which is that the build
dependencies between packages is not fully exposed --- when you
re-build librtems the testsuites do not detect this and therefore do
not re-build themselves.

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