Build: Difference between revisions

From SpaceElevatorWiki.com
Jump to navigationJump to search
No edit summary
No edit summary
 
(31 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Knowledge is Code =
'''Collecting and archiving knowledge is as important as code.''' Be diligent about linking to great documents (intro or reference) or writing cheat sheets. There is a ton of jargon out there and things are often much simpler than they sound.


----
Motion planning sounds fancy and I like using the word, but there is not much to it. In our repository in the docs directory, there is a paper that, despite lots of fluff, explains it well. We will do some good driving and motion planning in Milestone 1 with about 6,000 lines of C#! I hope that vision is also easier than it sounds, but I am less sure :-)
'''Why use Mercurial?'''
= Question =
One thing we should think about is whether we should dump tons of C/C++ into the tree just to build it once so we can then call it from C#. Maybe we could just dump the few release DLLs into the system and save people from having to compile the mess.


Mercurial is written in Python, is distributed has a solid community, has young code, etc.
We may change torcs, but likely not the Intel code, for example.
Bzr is built by Ubuntu, and does have some momentum, but I think Mercurial should and will win.
GIT is used by Linux but


The biggest difference from a client/server VCS (ala svn) to a distributed one is the idea that branches are used a lot more. In svn, branches are used when you want to do some long-term development on something. But in a distributed VCS you create one for every individual bug that you are working on. This provides a nice level of isolation between disparate thing you might be working on. Because of all this branching, distributed VCSs try to make branching a cheap operation.
= Coding stuff =
* [[Readability]]
= File Formats =
I took our slim torcsdata directory, which is 26 MB, and when I compressed it, I got it down to 11.6 MB. We should be looking for compressed file formats. Collada has a zip format that we could be using. We could be using JPEG or PNG rather than bitmaps.


And one way to make branching cheap is to do it locally. The "distributed" part of these tools comes from the fact that they are designed to work offline. This lets you commit changes and such to your local disk without requiring Internet access to hit a central repository online (but you can commit your changes to an online repository later when you are ready to). This is really handy if you develop on a laptop; it really sucks to have to do a bunch of coding remotely and then commit one huge patch instead of committing a bunch of individual patches. You want the atomicity of commits that represent a single piece of semantic change to allow better tracking of how/why your code changed, not some blob of code that changes a bunch of things at once. Plus it allows for easier rollback if you accidentally introduced a bug. From [http://sayspy.blogspot.com/2006/11/bazaar-vs-mercurial-unscientific.html]
= Launchpad =
[[Launchpad]]


Mercurial for CVS Users: http://www.selenic.com/mercurial/wiki/index.cgi/CvsConcepts
= Mercurial =
[[Mercurial]]


Some nice pictures: http://www.ivy.fr/mercurial/ref/v1.0/
Quick Reference: http://www.selenic.com/mercurial/hg.1.html


GUI tools: http://www.selenic.com/mercurial/wiki/index.cgi/GUIClients in Ubuntu, use "hg view"
= Building Intel Code =
[[Image:Ubuntu_8.04_OpenCV_Install_Guide.odt]]


Other good docs: http://www.selenic.com/mercurial/wiki/
= Building Torcs =


----
== Packages you need installed (Missing things?) ==
sudo apt-get install build-essential mesa-common-dev libsdl1.2-dev libgl1-mesa-dev libglu1-mesa-dev libsdl-image1.2 libsdl-image1.2-dev libalut-dev libopenal-dev plib1.8.4-dev freeglut3-dev libxi-dev libxmu-dev libxxf86vm-dev libxrandr-dev libmono-dev
 
== Common problems ==
''configure: error: Can't find libX11. Please check config.log and if you can't solve the problem send the file to torcs-users@lists.sourceforge.net with the subject "torcs compilation problem"
''
 
'''You should do: '''
 
./configure --x-libraries=/usr/lib --x-includes=/usr/include
 
= Building Ogre and OgreDotNet =
 
== Ogre ==
 
OgreDotNet complains if you do not have the NVidia Cg Toolkit Ogre plugin installed. It's not compiled in within ubuntu's ogre distribution, that is why we need to install Ogre3D from sources.
 
Dependencies :
* sudo aptitude install libzzip-dev libzzip-0-13 libxaw-headers libxmu-dev libxmu-headers libxpm-dev libfreeimage-dev libfreeimage3 libxrandr nvidia-cg-toolkit libfreetype6-dev libxaw7-dev
Get:
* http://downloads.sourceforge.net/ogre/ogre-v1-4-9.tar.bz2
 
./configure --prefix=/usr --enable-openexr && make && sudo make install
 
== OgreDotNet ==
 
Dependencies :
* sudo aptitude install swig cmake nant libmono-winforms2.0-cil
Get:
* svn checkout http://ogredotnet.googlecode.com/svn/trunk/ ogredotnet-read-only
 
Do not trust the README file : run ''bash ./build.sh''
 
''Who reads the readmes? You just tell us what to do :-)''

Latest revision as of 20:39, 17 February 2009

Knowledge is Code

Collecting and archiving knowledge is as important as code. Be diligent about linking to great documents (intro or reference) or writing cheat sheets. There is a ton of jargon out there and things are often much simpler than they sound.

Motion planning sounds fancy and I like using the word, but there is not much to it. In our repository in the docs directory, there is a paper that, despite lots of fluff, explains it well. We will do some good driving and motion planning in Milestone 1 with about 6,000 lines of C#! I hope that vision is also easier than it sounds, but I am less sure :-)

Question

One thing we should think about is whether we should dump tons of C/C++ into the tree just to build it once so we can then call it from C#. Maybe we could just dump the few release DLLs into the system and save people from having to compile the mess.

We may change torcs, but likely not the Intel code, for example.

Coding stuff

File Formats

I took our slim torcsdata directory, which is 26 MB, and when I compressed it, I got it down to 11.6 MB. We should be looking for compressed file formats. Collada has a zip format that we could be using. We could be using JPEG or PNG rather than bitmaps.

Launchpad

Launchpad

Mercurial

Mercurial

Quick Reference: http://www.selenic.com/mercurial/hg.1.html

Building Intel Code

File:Ubuntu 8.04 OpenCV Install Guide.odt

Building Torcs

Packages you need installed (Missing things?)

sudo apt-get install build-essential mesa-common-dev libsdl1.2-dev libgl1-mesa-dev libglu1-mesa-dev libsdl-image1.2 libsdl-image1.2-dev libalut-dev libopenal-dev plib1.8.4-dev freeglut3-dev libxi-dev libxmu-dev libxxf86vm-dev libxrandr-dev libmono-dev

Common problems

configure: error: Can't find libX11. Please check config.log and if you can't solve the problem send the file to torcs-users@lists.sourceforge.net with the subject "torcs compilation problem"

You should do:

./configure --x-libraries=/usr/lib --x-includes=/usr/include

Building Ogre and OgreDotNet

Ogre

OgreDotNet complains if you do not have the NVidia Cg Toolkit Ogre plugin installed. It's not compiled in within ubuntu's ogre distribution, that is why we need to install Ogre3D from sources.

Dependencies :

  • sudo aptitude install libzzip-dev libzzip-0-13 libxaw-headers libxmu-dev libxmu-headers libxpm-dev libfreeimage-dev libfreeimage3 libxrandr nvidia-cg-toolkit libfreetype6-dev libxaw7-dev

Get:

./configure --prefix=/usr --enable-openexr && make && sudo make install

OgreDotNet

Dependencies :

  • sudo aptitude install swig cmake nant libmono-winforms2.0-cil

Get:

Do not trust the README file : run bash ./build.sh

Who reads the readmes? You just tell us what to do :-)

Retrieved from "http://spaceelevatorwiki.com/wiki/index.php?title=Build&oldid=2422"