Re: msp430-elf-gcc (GCC) 4.9.1 20140707 (prerelease (msp430-14r1-10)) (GNUPro 14r1) (Based on: GCC 4.8 GDB 7.7 Binutils 2.24 Newlib 2.1)

That makes sense and is a good practice.

Could you ensure that the source tar files and support files include
that version information in the file name?  E.g.
msp430-gcc-source-2_x_x.tar.bz2 and msp430-gcc-support-2_x_1.zip?
Where the prefix "msp430-gcc-" is consistent (don't drop the "gcc"
unless the support files are supposed to work with CCS and IAR too);
"x" indicates a placeholder dont-care; and assuming that the build
number never involves any source changes so should pretty much always
be zero and can be dropped from source-only packaging.

It'd also be consistent with best practices if, when those archives
were unpacked, the contents appeared in a directory that matched the
base name of the tar file, rather than a bare unversioned "source" or
"include" directory.

This would carry the easy-to-identify information over to the parts of
the distribution that currently lack it.

Thanks for your consideration.

Peter

On Wed, Sep 10, 2014 at 10:30 AM, Pfeiffer, Markus <[email protected]> wrote:
> The versioning of our package works as follows:
>
> 1. Digit: GCC Version
> 2. Digit: Debug stack version
> 3. Digit: Header/linker file version
> 4. Digit: Build number
>
> This basically means that the delta from 2.0.0.0 to 2.1.1.0 is:
> - Identical GCC version
> - Updated Debug Stack
> - Updated header/linker files
>
> Why did we do this?
> We're shipping stand-alone packages & "distributions" that include all of the above. With the version scheme you instantly see if we just updated support files OR the debug Stack OR the actual compiler. This will hopefully help you to determine where you want to update or not.
>
> Markus
>
>
> Texas Instruments Deutschland GmbH, Haggertystr. 1, D-85356 Freising. Amtsgericht M?nchen HRB 40960. Gesch?ftsf?hrer: Dr. Wolfram Tietscher. Vorsitzender des Aufsichtsrates: Andreas Schwaiger
>
> -----Original Message-----
> From: Peter Bigot [mailto:[email protected]]
> Sent: Wednesday, September 10, 2014 5:13 PM
> To: Ben Ransford
> Cc: Kees Schoenmakers; GCC for MSP430 - http://mspgcc.sf.net
> Subject: Re: [Mspgcc-users] msp430-elf-gcc (GCC) 4.9.1 20140707 (prerelease (msp430-14r1-10)) (GNUPro 14r1) (Based on: GCC 4.8 GDB 7.7 Binutils 2.24 Newlib 2.1)
>
> On Wed, Sep 10, 2014 at 9:31 AM, Ben Ransford <[email protected]> wrote:
>> On Sep 10, 2014, at 7:19 AM, Kees Schoenmakers <[email protected]> wrote:
>>> I found the archives for the newest msp430-gcc on the TI site via .
>>> http://www.ti.com/tool/MSP430-3P-GCC-MSPGCC-TPDE
>>
>> The "production" version of GCC for MSP430, which TI announced* on
>> August 18, lives here:
>>
>>   http://www.ti.com/tool/msp430-gcc-opensource
>>
>> ... whereas the URL you mentioned seems to refer to a beta release.
>>
>> I don't know whether the production version fixes the syntax error you
>> saw, but perhaps it's worth a try.
>
> TI seems to change the naming conventions of the source releases with each package, which also makes it difficult to figure out what's going on.  2.00.00's msp430-gcc-14r1-10-source.tar.bz2 is bitwise identical to 2.01.01's msp430-gcc-source.tar.bz2.  Either there is no difference in the toolchain between 2.00.00 and 2.01.01, or the source archive
> http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/exports/msp430-gcc-source.tar.bz2
> was not updated.
>
> The 2.01.01 headers files in
> http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/exports/msp430-support-files.zip
> are slightly different: USBRAM sections in linker files, cleanup of some RTC defines.
>
> Neither situation would fix the issue with the interrupt declaration; I don't know what the problem is there; probably the new toolchain requires a different interrupt declaration syntax than you're using.
>
> Peter
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk