Version Number in RTEMS Tools

2015-11-17 Thread Joel Sherrill
Hi

The answer may be "don't do that" but I was configuring for 4.11
on the master and the dynamic loading tools now have 4.12
hard coded. Everything built up to that point.

Is there anyway to be more flexible or is this just a matter of even
though the master can still be built with 4.11 tools, this bump forces
a distinction.

Usually the forced bump for tools is a newlib or gcc incompatibility.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Version Number in RTEMS Tools

2015-11-17 Thread Chris Johns
On 18/11/2015 10:01 AM, Joel Sherrill wrote:
> 
> The answer may be "don't do that" but I was configuring for 4.11
> on the master and the dynamic loading tools now have 4.12 
> hard coded. Everything built up to that point.
> 
> Is there anyway to be more flexible or is this just a matter of even
> though the master can still be built with 4.11 tools, this bump forces
> a distinction.

If we have tool sets (gcc etc) with version numbers then you need to
match the tool set's version with the RTEMS version and the RTEMS tools
version. I cannot see a way around this. I am open to any suggestions.
This was the reason I asked about the purpose of this version number and
if it could be removed.

I suppose I could add an option to override the inbuilt version number.
Is this a good idea? The issue is now to the manage the option.

> 
> Usually the forced bump for tools is a newlib or gcc incompatibility.
> 

I suppose this is just something else to add to the list.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel