rtems - RTEMS Kernel, file-systems, drivers, BSPs, samples, and testsuite.

	Commit message (Collapse)	Author	Files	Lines
2000-05-28	These files were added or deleted on the 4.5 branch as part of	Joel Sherrill	1	-390/+0
	Ralf's patch to split the .spec files into multiple ".add" parts.
2000-02-08	Patch from David Fiddes <D.J.Fiddes@hw.ac.uk> to match his Cygwin	Joel Sherrill	1	-2/+2
	for RTEMS toolkit.
2000-01-31	Patch rtems-rc-20000118-1.diff from Ralf Corsepius <corsepiu@faw.uni-ulm.de>	Joel Sherrill	1	-102/+160
	that contains: * cleanups to configuration files * A reworked gccnewlib.spec.in: I have reformated it for enhanced readability and added more rtems-base packages. It now should be free of any installation conflicts (If there still remain some, they should be regarded as bugs). * A fix to the bin2boot RTEMS_BSP issue (make RTEMS_BSP="pc386 pc486" now works). * removes libbsp/bare/wrapup * Further cleanups
2000-01-24	Attempting to split binutils and gcc into base/shared and CPU specific	Joel Sherrill	1	-10/+25
	packages.
2000-01-23	Patch from David Fiddes <D.J@fiddes.surfaid.org> which adds basic	Joel Sherrill	1	-14/+14
	Cygwin support to the RPM scripts. The patch from David did not apply cleanly and Joel ended up making all the modifications plus some it should have included for consistency by hand. His comments: I've included a diff against the last (19991203) snapshot RPM scripts that adds what I think is required for Cygwin support. Basically all this boils down to is adding EXE extension support. I've added the AC_EXEEXT rule to conifgure.in (requires a valid 'cc' to work - this is not available in the standard Cygwin distro). Each of the .spec.in have @exe_ext@ includes in them for each program that results in an EXE. The only odity here is that the chill driver program is a shell script and thus does not require .exe to be added... The mk.in have all been updated to process the new exe_ext rule.
1999-10-27	Latest version from Ralf Corsepius <corsepiu@faw.uni-ulm.de> which	Joel Sherrill	1	-44/+103
	splits gcc, gcj, chill, f77 and objc into separate rpms..
1999-10-25	Patch generated from scripts-19991025-0.tar.gz from	Joel Sherrill	1	-34/+113
	Ralf Corsepius <corsepiu@faw.uni-ulm.de>: Most significant changes: * Names for rpms changed again * gccnewlib.rpm split into 3 rpms, one for chill, gcj, gcc (includes c/c++/f77/objc), simultaneously built from a common .spec. small patches with major impact to gcc and newlib (Those fixes mentioned to Ian, ie. libobjc/libchill are built, multilibing works) * gcc patch against gcc-2.95.2 (Should also apply to gcc-2.95.1 without major problems) * Buildroot removed from /spec.in * New: rpm Group: "rtems" (rpm -q -g rtems reports all RTEMS packages)
1999-10-25	Merged scripts-19991022-0 changes from Ralf.	Joel Sherrill	1	-46/+35

1999-10-21	Now builds RPM without complete source. Each target is only 15K.	Joel Sherrill	1	-3/+16

1999-10-21	Now can specify rpm_build_root via setup.	Joel Sherrill	1	-2/+2
	Changed package name so generated RPM would have a nicer name.
1999-10-21	Changes from Ralf with script-19991021-0. He fixed the %files	Joel Sherrill	1	-11/+45
	issue and has mkbspspec in a better state. user.cfg is now gone. There are some miscellaneous changes to buildall done by Joel to clean up the build process.
1999-10-20	Moved stuff to rtems subdirectory and made sure the system still	Joel Sherrill	1	-34/+36
	functioned. Merged Ralf's changes into gccnewlib.spec.in.
1999-10-20	Miscellaneous improvements and cleanups committed so I can merge	Joel Sherrill	1	-1/+2
	Ralf's end of day version.
1999-10-20	New version from Ralf.	Joel Sherrill	1	-30/+38

1999-10-20	Committing changes before Ralf's changed.	Joel Sherrill	1	-0/+15

1999-10-19	Left to build overnight.	Joel Sherrill	1	-3/+3

1999-10-19	Easier to insert tool version number.	Joel Sherrill	1	-11/+11

1999-10-18	Making sparc-rtems rpms available.	Joel Sherrill	1	-0/+1

1999-10-18	Working on being able to cut RPMs. It now appears that the process	Joel Sherrill	1	-0/+116
	is working mostly for sparc at least. There is one major problem -- the current process generates a unique source file per RPM when in fact all of the source files are nearly the same -- it is only the spec part of the rpm which differs. The new file mkbinutils_subpackage_version is an attempt to address this. It does part of the job right -- one source file produces multiple binary RPMs. BUT the end user can not produce the resulting RPMS themselves from SRPMS unless they also build all targets.