[RTEMS Project] #2540: RSB has problems building into existing directory
RTEMS trac
trac at rtems.org
Thu Nov 15 00:45:51 UTC 2018
#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
More information about the bugs
mailing list