[RTEMS Project] #2540: RSB has problems building into existing directory

[RTEMS trac]

#2540: RSB has problems building into existing directory
----------------------------+----------------------------
 Reporter:  Simon Williams  |       Owner:  Needs Funding
     Type:  defect          |      Status:  assigned
 Priority:  normal          |   Milestone:  Indefinite
Component:  tool/rsb        |     Version:  5
 Severity:  normal          |  Resolution:
 Keywords:                  |  Blocked By:
 Blocking:                  |
----------------------------+----------------------------

Comment (by Chris Johns):

 Replying to [comment:11 Sebastian Huber]:
 > I have absolutely no confidence in the GCC build system.

 I do not know gcc's build system enough to comment. It is a bit of a
 beast.

 > I am not sure if this will ever work reliably.

 I see value in what you are asking and it raises the important broader
 question of "What a `$prefix` tree of RTEMS tools means?". We currently
 assume a release `$prefix` is a single release however there are **no**
 checks made. You are in fact asking we create a new policy that the RSB
 has avoided until now. Such a policy will exist for ever so I think it
 would be good to flesh out what it is and what it means.

 > I would
 >
 > 1. try to detect that an installation exists in the prefix,

 Does this mean we can update a single variant of a package in the
 `$prefix` and not the other variants? Do we allow a user to have an arch
 of one build and another arch on a different build?

 Is the detect test per package or common to all packages? If common to all
 packages, ie in the RSB's python, how would you implement it? I think a
 common test is too hard.

 A per-package test could be implemented with a worker script called from
 the config script using `$()`. I did this in the gdb config to find the
 Python header and library before building gdb. The issue here is
 implementing the test in each step that matters in a package's build, ie
 the binutils and gcc for tool sets.

 GCC has the RSB hash embedded in it and can be found with:
 {{{
 $prefix/arm-rtems5-gcc --version | awk ' /.*-gcc/ { print substr($8, 1,
 length($8) - 1); }'
 30da0c720b78eba16a3f5272206c07415368617b
 }}}

 Can an RSB hash be added to the GNU `as` and `ld` version string? I think
 this would be needed to make adding any test worthwhile.

 > 2. stop building if an installation exists unless a special option is
 given..

 I am not a fan of adding extra options. I do not see a need at this point
 in time. I feel removing installed files or attempting to automatically
 clean up is a complex hole we should avoid. We could just document what
 users need to do if they see warnings or errors.

 How would you build more than one variant of a packages, ie different arch
 tool sets? This feeds back to the per-package vs all packages testing of
 installed packages.

 Do we stop for all build types or just release builds? We have two
 contexts, a development context where we are working with different tool
 sets and sometimes in different configurations and then we have the
 release context. Maybe in the development context a warning is printed and
 in the release context an error is produced.

--
Ticket URL: <http://devel.rtems.org/ticket/2540#comment:13>
RTEMS Project <http://www.rtems.org/>
RTEMS Project