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
projects.
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):
libgmp
libmpfr
zlib
tcl
tk
itlc
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
whole).
To be honest, your (RedHat + TI) way is worst possible one :-(
--
Best regards,
Lev mailto:l...@serebryakov.spb.ru
------------------------------------------------------------------------------
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
