Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Different versions of TPTP from a build perspective"
| Line 1: | Line 1: | ||
The intent of this mini-doc is to record the changes necessary to introduce a new version of the platform/data collection component, at least as it affects the build at Intel. Given that a new version was to be introduced, 4.2.1.1, I chose this as the opportunity to record the things I had to do to handle that new version here so that those that follow can know what to do... and what might need to be automated in the future. I'm updating this mini-doc with the migration from 4.3.0 to 4.4.0 with an eye towards transitioning our end of things in the future. The items listed here are refined so that the 4.2.1.1 => 4.2.2 build migration can go smoothly. | The intent of this mini-doc is to record the changes necessary to introduce a new version of the platform/data collection component, at least as it affects the build at Intel. Given that a new version was to be introduced, 4.2.1.1, I chose this as the opportunity to record the things I had to do to handle that new version here so that those that follow can know what to do... and what might need to be automated in the future. I'm updating this mini-doc with the migration from 4.3.0 to 4.4.0 with an eye towards transitioning our end of things in the future. The items listed here are refined so that the 4.2.1.1 => 4.2.2 build migration can go smoothly. | ||
| − | The three | + | The three Windows systems do their builds in the /home/build/TPTP/<version-number>/TPTP-<version-number>-<timestamp> subdirectory. This is not possible if there is not already a /home/build/TPTP/<version-number> subdirectory already in place, so creation of those subdirectories is necessary. This also represents a good checkpoint whereby you can ensure that the automatic login via ssh works for the build engineer's login. (Automatic login is done via the ~/.ssh/known_hosts file.) |
| − | Build migration time is a good opportunity to remind us to explore /home/build/TPTP/*/* anyway to see if there are any outdated builds that could stand cleaning up. I usually keep the builds from the last month or so, and remove the rest. Don't worry about losing the build results; they're kept up on the Eclipse archive site. | + | Build migration time is also a good opportunity to remind us to explore /home/build/TPTP/*/* anyway to see if there are any outdated builds that could stand cleaning up. I usually keep the builds from the last month or so, and remove the rest. Don't worry about losing the build results; they're kept up on the Eclipse archive site. |
| − | It's a little more complicated on the Linux boxes. There, the builds are done in the /home/proj/tptp/builder/<arch>/TPTP/<version-number>/TPTP-<version-number>-<timestamp> subdirectory. As for | + | It's a little more complicated on the Linux boxes. There, the builds are done in the /home/proj/tptp/builder/<arch>/TPTP/<version-number>/TPTP-<version-number>-<timestamp> subdirectory. As for Windows, you'll need to create the /home/proj/tptp/builder/<arch>/TPTP/<version-number> subdirectories, where <arch> is ia32, em64t, and ipf. Most importantly, the build assumes that in this subdirectory will be found a "depends" symlink to the software needed to do the build (the appropriate Java). Make sure to replicate the "depends" symlinks found in the other version-number associated subdirectories. |
Revision as of 17:03, 13 December 2006
The intent of this mini-doc is to record the changes necessary to introduce a new version of the platform/data collection component, at least as it affects the build at Intel. Given that a new version was to be introduced, 4.2.1.1, I chose this as the opportunity to record the things I had to do to handle that new version here so that those that follow can know what to do... and what might need to be automated in the future. I'm updating this mini-doc with the migration from 4.3.0 to 4.4.0 with an eye towards transitioning our end of things in the future. The items listed here are refined so that the 4.2.1.1 => 4.2.2 build migration can go smoothly.
The three Windows systems do their builds in the /home/build/TPTP/<version-number>/TPTP-<version-number>-<timestamp> subdirectory. This is not possible if there is not already a /home/build/TPTP/<version-number> subdirectory already in place, so creation of those subdirectories is necessary. This also represents a good checkpoint whereby you can ensure that the automatic login via ssh works for the build engineer's login. (Automatic login is done via the ~/.ssh/known_hosts file.)
Build migration time is also a good opportunity to remind us to explore /home/build/TPTP/*/* anyway to see if there are any outdated builds that could stand cleaning up. I usually keep the builds from the last month or so, and remove the rest. Don't worry about losing the build results; they're kept up on the Eclipse archive site.
It's a little more complicated on the Linux boxes. There, the builds are done in the /home/proj/tptp/builder/<arch>/TPTP/<version-number>/TPTP-<version-number>-<timestamp> subdirectory. As for Windows, you'll need to create the /home/proj/tptp/builder/<arch>/TPTP/<version-number> subdirectories, where <arch> is ia32, em64t, and ipf. Most importantly, the build assumes that in this subdirectory will be found a "depends" symlink to the software needed to do the build (the appropriate Java). Make sure to replicate the "depends" symlinks found in the other version-number associated subdirectories.