Hello DJ,

Sunday, October 18, 2015, 9:08:34 PM, you wrote:

>>  Yep, it works, modulo DESTDIR problems, which could be easily patched.
> We've always used a separate --prefix for each release (typically
> /opt/redhat/msp430-YYMMDD/) so we wouldn't notice.
 When it is build for system package (like RPM, DEB or Gentoo Portage) it
should has proper (final) prefix (like /usr/local/ti-gcc-${version}) but
"make install" must place it in "stage" directory for packaging. It is
typically done with DESTDIR (so, destination becomes $(DESTDIR)$(PREFIX),
not just $(PREFIX), and it is supported by all autotools/libtools

  But, as I say, it is very minor problem, as it could be easily patched by
 me (package maintainer), it is only 3KiB of patches, which is negligible :)

>>  I'm not sure, that toolchain need all these separate tcl and tk
>>  stuff (system already has them!), but it is better than nothing
>>  (though, very Windows-like!).
> No surprise, we support windows :-)
  Yep, I know :)

> And not all Unix-y systems have those, either.  Even Linux is the user
> hasn't chosen to install them yet (which is commonly the case).
 Yes. But typical *IX way is to use package managers for each separate
component. Ideally, all this stuff, which is not MSP430-dependand (build for
host and could be used by many oither packages and programs in same system):


 should be mentioned in requirements and installed by means of system
 package manager (rmp, apt-get, Gentoo Portages, NetBSD pkg-src, FreeBSD
 ports, etc). For example, msp430 package contains old versions of gmp and mpfr.
 Are you sure, that packaged versions doesnt have bugs and, may be, even
 security ones?

 IMHO, ideal source-based releasing of toolcahin looks like this:

  (1) List of requirements, like "libgmp > 5.1.0, mprf > 3.1.0" and so on.
      NO SOURCES of all these libraries should be provided, as they are
      SEPARATE projects.

  (2) Links to some official binutils / gcc / gdb RELEASE tarballs (gcc 4.9.1,
      for example).

  (3) Minimal patches for (2), which is msp430-dependant.

  (4) System headers, linker scripts, stuff like this.

  (5) Some script to build toolchain from all parts above
     (unpack-patch-configure-build in proper order).

  It is ideal situation, which allows to package your work for differnet
 distributives in most natural way.

  Second-to-best way is like ARM does: script, which, really, allows to
 build toolchain with system libraries (but binutls/gcc/gdb are packaged as

  To be honest, your (RedHat + TI) way is worst possible one :-(

Best regards,
 Lev                            mailto:l...@serebryakov.spb.ru

Mspgcc-users mailing list

Reply via email to