Difference between revisions of "Winter 2010 Posters/GCC4.5 Packaging/ViewSource Packaging"
(→Results + What we’ve accomplished) |
(→Acknowledgements and Links) |
||
| (21 intermediate revisions by 2 users not shown) | |||
| Line 8: | Line 8: | ||
= Description of work + goals = | = Description of work + goals = | ||
| + | * Goal | ||
| − | Our | + | Our Primary Goal and Focus was to package the DXR 'viewsource' web application tool and dependencies, (Dehydra and Jshydra), as a first step towards packaging the full DXR system for wide, reliable distribution. DXR contains components such as Dehydra, Jshydra, Viewsource, and a Modified GCC compiler. DXR was originally created by David Humphrey as an experiment. |
| − | Definition of | + | *Definition of Packaging |
| − | + | Packaging is defined as the process of archiving files together along with information about the package, like its current version, a description of what the package is meant to do, etc. Packages are deployed in order to solve a software issue or resolve a package dependency. | |
| + | |||
| + | Packages are all grouped together in what are called "Package Repositories" developed and maintained by "Repo Masters". This is where the packages come from when you "yum install" any package off your machine. The DXR repository is located on scotland and can be accessed through the web browser - [http://scotland.proximity.on.ca/DXR/ DXR] | ||
*Dehydra | *Dehydra | ||
| − | Dehydra is a static analysis | + | Dehydra is a static analysis tool able to analyze application specif C++ codes. Dehydra can be compared to as a searching tool as well. It is able to display a vast amount of information consisely using Javascripts. This tool is able to help fromo bugs in source codes, which is provides more error checking than C++ is able to by itself. Dehydra is a plugin for GCC, which make it easy to use for projects that supports GCC. |
*JSHyrda | *JSHyrda | ||
JSHydra is static tool that is able to analyze general JavaScript Code. It was formed with the concept of previous tools Dehydra and Treehydra, which performs C++ code analysis. The backend of this tool, breaks down the Javascript code using a SpiderMonkey Engine. The breakdown of the codes are executed by running Javascripts. | JSHydra is static tool that is able to analyze general JavaScript Code. It was formed with the concept of previous tools Dehydra and Treehydra, which performs C++ code analysis. The backend of this tool, breaks down the Javascript code using a SpiderMonkey Engine. The breakdown of the codes are executed by running Javascripts. | ||
| − | |||
*Viewsource | *Viewsource | ||
| Line 34: | Line 36: | ||
= Results + What we’ve accomplished = | = Results + What we’ve accomplished = | ||
| + | * Viewsource | ||
Viewsource was built and has been deployed on one of the CDOT machine’s, everything was ready and waiting for Dehydra + Jshydra. | Viewsource was built and has been deployed on one of the CDOT machine’s, everything was ready and waiting for Dehydra + Jshydra. | ||
(Viewsource Screenshot) | (Viewsource Screenshot) | ||
| + | |||
| + | |||
Both Dehydra and Jshydra where built and finished with no errors that we knew of, although the true test would be when we incorporate GCC with it. So far Viewsource and Dehydra are ready for fedora review while Jshydra still has to be prepared. | Both Dehydra and Jshydra where built and finished with no errors that we knew of, although the true test would be when we incorporate GCC with it. So far Viewsource and Dehydra are ready for fedora review while Jshydra still has to be prepared. | ||
| Line 51: | Line 56: | ||
(Dehydra Screenshot 64 + 32 bit) | (Dehydra Screenshot 64 + 32 bit) | ||
| − | |||
| + | * GCC | ||
| + | |||
| + | The challenge we face on the final part of the project is to build on a beta release of a compiler. Luckily for us we are able to reference our work with an earlier version of this compiler. | ||
| + | |||
| + | The first task was to create a SPEC file. A SPEC file is file that has a list of instructions that will be used by a building tool to build our packages. The problems we faced with our build are a bunch or errors linking back to libraries that it cannot find and incorrect path names. After lots of Google searching and communication on Seneca’s Channel on IRC, we were able to fix that issue. The solutions to our problems are using the correct options to build and use patches that will alter the code. After solving the issue we continued to build but this time we came across an issue, that even Google cannot help us with. To try to fix our issue we tried to email the package create of GCC, but sadly we did not hear back from them. | ||
| − | (build-failure-64bit.png) + | + | Since our attempt to create a SPEC file was a disaster, we copied the SPEC file from the previous release of an older package and modified it to fix our needs. With the numerous amount of modification to the SPEC file we started the build process, unlike our scratch SPEC file, the build times were significantly less. The errors would happen in the earlier stage of the build. These errors consist of missing dependencies, missing files, missing paths to directories. The missing dependencies are a easy fix, I just needed to install them, but the missing files, and other errors we had trouble solving. Again with communication in the Fedora community, we were unable to solve it. A suggestion was to do a command line build. |
| + | |||
| + | After speaking with the Fedora community, they suggested that we try to do a command line build from the GCC 4.5 tarball. With their advice, we extracted the GCC 4.5 file and started building from command line. The result of the compile the source and install it successfully into our system. | ||
| + | |||
| + | Now our remaining task is to compare the configuration settings between the source and our build tool and work around our findings. Until we can figure this problem, our project is on a stand still. | ||
| + | |||
| + | (build-failure-64bit.png) + (build-failure-32bit.png) | ||
= Summary and set of conclusions = | = Summary and set of conclusions = | ||
| − | All of the other fundamental components are built however our project is still | + | All of the other fundamental components are built however our project's completion process is still being impeded due to GCC. Once GCC is finished it will be tested with the other components and then GCC and jshydra will be prepped according to the fedora review guidelines and we will have our DXR complete. |
= Acknowledgements and Links = | = Acknowledgements and Links = | ||
| − | + | * Chris Tyler - http://blog.chris.tylers.info/ | |
* Boris Chao Blog - http://blog.bchao.ca | * Boris Chao Blog - http://blog.bchao.ca | ||
* Jonathan Deni Blog - http://jonathandeni.blogspot.com/ | * Jonathan Deni Blog - http://jonathandeni.blogspot.com/ | ||
* DXR Website - http://dxr.proximity.on.ca/dxr/ | * DXR Website - http://dxr.proximity.on.ca/dxr/ | ||
* Dehydra - https://developer.mozilla.org/en/Dehydra?rdfrom=https%3A%2F%2Fwiki.mozilla.org%2Findex.php%3Ftitle%3DDeHydra%26redirect%3Dno | * Dehydra - https://developer.mozilla.org/en/Dehydra?rdfrom=https%3A%2F%2Fwiki.mozilla.org%2Findex.php%3Ftitle%3DDeHydra%26redirect%3Dno | ||
| − | *Fedora Project - http://fedoraproject.org/ | + | * Fedora Project - http://fedoraproject.org/ |
* GCC - http://gcc.gnu.org/ | * GCC - http://gcc.gnu.org/ | ||
* JSHydra - https://developer.mozilla.org/en/JSHydra | * JSHydra - https://developer.mozilla.org/en/JSHydra | ||
| + | * Project Repo - http://scotland.proximity.on.ca/DXR/ | ||
= Logos = | = Logos = | ||
Latest revision as of 03:30, 18 April 2010
Contents
Project Name
DXR Project
Names
Jonathan Deni & Boris Chao
Description of work + goals
- Goal
Our Primary Goal and Focus was to package the DXR 'viewsource' web application tool and dependencies, (Dehydra and Jshydra), as a first step towards packaging the full DXR system for wide, reliable distribution. DXR contains components such as Dehydra, Jshydra, Viewsource, and a Modified GCC compiler. DXR was originally created by David Humphrey as an experiment.
- Definition of Packaging
Packaging is defined as the process of archiving files together along with information about the package, like its current version, a description of what the package is meant to do, etc. Packages are deployed in order to solve a software issue or resolve a package dependency.
Packages are all grouped together in what are called "Package Repositories" developed and maintained by "Repo Masters". This is where the packages come from when you "yum install" any package off your machine. The DXR repository is located on scotland and can be accessed through the web browser - DXR
- Dehydra
Dehydra is a static analysis tool able to analyze application specif C++ codes. Dehydra can be compared to as a searching tool as well. It is able to display a vast amount of information consisely using Javascripts. This tool is able to help fromo bugs in source codes, which is provides more error checking than C++ is able to by itself. Dehydra is a plugin for GCC, which make it easy to use for projects that supports GCC.
- JSHyrda
JSHydra is static tool that is able to analyze general JavaScript Code. It was formed with the concept of previous tools Dehydra and Treehydra, which performs C++ code analysis. The backend of this tool, breaks down the Javascript code using a SpiderMonkey Engine. The breakdown of the codes are executed by running Javascripts.
- Viewsource
Viewsource is a web-based interface to Mozilla's static analysis tools, Dehydra and JShydra. Dehydra is used to analyze C/C++ source code and JShydra is used to analyze JavaScript. Essentially you would take source code and place it into the textbox provided in the web application and select either the JShydra or Dehydra button and view the output.
- GCC (GNU Compiler Collection)
GCC is a compilation of compilers, and was originally written for the GNU operating system. Here is a list of front end compilers in its collection: C, C++, Objective-C, Fortran, Java, and Ada, as well as libraries for these languages.
Results + What we’ve accomplished
- Viewsource
Viewsource was built and has been deployed on one of the CDOT machine’s, everything was ready and waiting for Dehydra + Jshydra.
(Viewsource Screenshot)
Both Dehydra and Jshydra where built and finished with no errors that we knew of, although the true test would be when we incorporate GCC with it. So far Viewsource and Dehydra are ready for fedora review while Jshydra still has to be prepared.
- Dehydra
Our challenge in building Dehydra is there are no prior package release of this tool as we are the first ones to create it, so we had nothing to refer to and check if we are doing everything correctly.
Our solution was to follow the installation guide off the Mozilla Dehydra site, and built a spec file around it. During the process I have encountered lots of small errors, with the help and reviewing Fedoras Packaging outline, we were able to overcome these obstacles. Most of these errors are related to where I install the files at the end of the installation.
At the end, we were able to build the Dehydra package. We created two packages one for the x86-64 architecture and one for the i386 architecture. At this current stage and time we are unable to test out the package to see if it works. We are waiting for our other project (GCC Packaging) to complete in order to test it as they go hand in hand. We have placed our packages in our repo and can be accessed at any time.
(Dehydra Screenshot 64 + 32 bit)
- GCC
The challenge we face on the final part of the project is to build on a beta release of a compiler. Luckily for us we are able to reference our work with an earlier version of this compiler.
The first task was to create a SPEC file. A SPEC file is file that has a list of instructions that will be used by a building tool to build our packages. The problems we faced with our build are a bunch or errors linking back to libraries that it cannot find and incorrect path names. After lots of Google searching and communication on Seneca’s Channel on IRC, we were able to fix that issue. The solutions to our problems are using the correct options to build and use patches that will alter the code. After solving the issue we continued to build but this time we came across an issue, that even Google cannot help us with. To try to fix our issue we tried to email the package create of GCC, but sadly we did not hear back from them.
Since our attempt to create a SPEC file was a disaster, we copied the SPEC file from the previous release of an older package and modified it to fix our needs. With the numerous amount of modification to the SPEC file we started the build process, unlike our scratch SPEC file, the build times were significantly less. The errors would happen in the earlier stage of the build. These errors consist of missing dependencies, missing files, missing paths to directories. The missing dependencies are a easy fix, I just needed to install them, but the missing files, and other errors we had trouble solving. Again with communication in the Fedora community, we were unable to solve it. A suggestion was to do a command line build.
After speaking with the Fedora community, they suggested that we try to do a command line build from the GCC 4.5 tarball. With their advice, we extracted the GCC 4.5 file and started building from command line. The result of the compile the source and install it successfully into our system.
Now our remaining task is to compare the configuration settings between the source and our build tool and work around our findings. Until we can figure this problem, our project is on a stand still.
(build-failure-64bit.png) + (build-failure-32bit.png)
Summary and set of conclusions
All of the other fundamental components are built however our project's completion process is still being impeded due to GCC. Once GCC is finished it will be tested with the other components and then GCC and jshydra will be prepped according to the fedora review guidelines and we will have our DXR complete.
Acknowledgements and Links
- Chris Tyler - http://blog.chris.tylers.info/
- Boris Chao Blog - http://blog.bchao.ca
- Jonathan Deni Blog - http://jonathandeni.blogspot.com/
- DXR Website - http://dxr.proximity.on.ca/dxr/
- Dehydra - https://developer.mozilla.org/en/Dehydra?rdfrom=https%3A%2F%2Fwiki.mozilla.org%2Findex.php%3Ftitle%3DDeHydra%26redirect%3Dno
- Fedora Project - http://fedoraproject.org/
- GCC - http://gcc.gnu.org/
- JSHydra - https://developer.mozilla.org/en/JSHydra
- Project Repo - http://scotland.proximity.on.ca/DXR/
Logos
- Fedora
- Seneca
- gcc
- Mozzila
Pictures
All pictures can be found here http://hongkong.proximity.on.ca/bchao/sbr700
