#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
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs