Build issue

[Claus, Ric]

On May 12, 2012, at 9:08 AM, Gedare Bloom 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 :))

Correct.  (Thanks for the rtems-devel pointer.)

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

If it is a known, recognized, issue that won't be fixed, then there's not much point in filing a bug report for it.  Since it's been there for the two years that I've been involved with RTEMS, I must either be doing something wrong or it is an accepted issue.

Perhaps a new build system might make a good student project, if properly supervised by a knowledgeable person (i.e., not me).  It's the kind of thing that one is periodically faced with and is a useful skill to have.  It also has a large impact because it causes a lot of grousing and frustration if it isn't done right.

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

I agree.  "In most cases" makes me particularly uncomfortable.

	Ric

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