DEVS: Building from source
Precursor:
Development on this project is not really intended for the beginner. If, after reading this post, you do not understand at least 90% of what I have said, then working development on this project may not be for you.
A few folks might be wondering how they can get involved with development. this project basically has two 'development' areas where people can contribute.
1) Finding offsets after an update.
2) Improving the actual server/client code
#1 above is probably the most important one that most people with even moderate developer experience can contribute. Sometimes finding offsets is easy, sometimes not. Most people rely on one or two folks to get the offsets. It is not that hard, and I recently added some debug modes to the server to aid in the finding of these offsets. New offset requests should be posted in the Help forums. New releases will be posted in the 'News' forum. Please refrain from asking for offsets in the News forum... because that is not news.
If you would like to contribute to #2, or are just interested in looking at the source, you may do that as well. First, understand that the source code is housed inside a SourceForge (SF) CVS repository. This is the entity which actually holds the source code, and is available to anyone at anytime. Source code is not normally shipped in binary releases. It is a waste of SourceForge resources and bandwidth to do so. People have several at least two ways to obtain source, they do not need a third. By putting source in the binary release, you are making SF house 2 copies of your source, one in the repository, and one in the release. Totally unnecessary. Also, because this product only works on Windows, and most users do not build from source, there is no need to create a source release.
I recommend to anyone who wants to work with SF, that they obtain Cygwin at http://www.cygwin.com/ . Run the setup tool, download whatever development packages you feel you need. You should make sure the CVS tool is part of the download/install.
I also recommend using the PuttyCyg tool, which can be downloaded from http://code.google.com/p/puttycyg/ . This is basically a port of Putty that allows one to connect to your local Cygwin setup. This is purely optional, but gives you a more robust terminal to work from.
Once Cygwin is working, you will want to get your hands on the source code. Visit SF at http://sourceforge.net/cvs/?group_id=10131 and read the instructions for setting up your CVS environment.
The minimum commands you need to perform an anonymous download of the source code.
First, Login to the CVS server on sourceforge. There is no password, so just hitting enter at the password prompt should be sufficient.
Next, you check out a copy of the module you wish to download. If you wanted to get a copy of the current latest source code (HEAD) you would issue the command:
If you wanted to download a specific version of a module, the command is slightly different. You specify the tag you want to download of the module. Where in this case you may want to get the Release Version 1.19.2 for the myseq module.
The next step is to actually build the binaries. To do this you will need a relatively new version of a Windows development toolkit. The one I use is the freely downloadable, Microsoft Visual Express, which is a stripped down derivative of the new Microsoft Visual Studio suite. Microsoft has decided to continue the free use of the Express Suites. You can download it at http://www.microsoft.com/express/ .
The server is built using C++ and the Microsoft Platform SDK. It is a native Win32 console application, and hence does not require NET to run. It requires a C++ compiler to build. I use Express C++. You can also grab the x86 PSDK here at http://www.microsoft.com/downloads/d...displaylang=en .
Note: The server may require a Micrsoft runtime DLL in order to run correctly. This dll is called msvcr80.dll, and is usally located in the \windows\winsxs folder. This appears to be a side effect of using the 'safe' functions and Visual Express (or Visual Studio 2005). I imagine as time passes, this dll will become part of regular windows, but until then, people may need to obtain it. I am fairly certain that installing NETv2.0 gives you this dll, although some people claim they need needed to install Visual Express to get it. Typically this should be shipped with the application, so I may decide to ship it in future releases.
The client is built using C#. It is a CLR application that also requires three royalty free DLLs that the originator paid for for use with this project. The client requires the NET runtimes to be installed on any machine that will run the client, but to build the client you must also install the NET SDK. I use Express C# to build the client, which requires NETv2.0, so any client I build requires NETv2.0 runtime to run, and NETv2.0 SDK to build.
You can get the NETv2.0 runtimes here at http://www.microsoft.com/downloads/d...displaylang=en
You can get the NETv2.0 SDK here at http://www.microsoft.com/downloads/d...displaylang=en
I have included new 'solution' files for the MS Express suite, which will load and setup the build environment for both the client and the server. They are aptly named MySEQ.server.sln and MySEQ.client.sln. I left the old solution files for anyone who still wants to use an old tool suite, although I cannot vouch if any of it still works.
I have setup the solution and project files so that there is no need to perform any 'tweaks' to your system just because you installed the PSDK. You should be able to just install Express C++, Express C#, NET2.0, NET2.0 SDK, PSDK x86 and that is it. It should just build right out of the box.
Because the client is GUI based, I strongly urge folks to use the IDE. To that end, I, myself, will not put any effort into making a non-IDE build method, or to maintain it's functionality. It's just not worth the effort in my opinion. If someone else feels differently, then by all means, invest the effort to make it work.. just don't break the IDE build environment files.
================================================== =
Making changes:
If you are a project developer then you have commit privileges already. Just make sure that you are working off the current HEAD and keep your changes checked into CVS, with appropriate comments. If you make a release, please tag it! I prefer if people actually build releases from tags, but if not, at the very least tag the code at the time you build. Use the following naming convention:
release_1-18-1
You cannot use periods in the release name, so use hyphens in their place. Use the same release naming convention for both the server and client code. If you MUST build a branched release, make the tag into a branch tag and use branching correctly. Do not rollback changes in the HEAD! If you need assistance, send me a email and I will help you out.
If you are not a project developer, you will need to generate a patch file using:
cvs diff
Zip up the output and attach it here with an explanation of what you did and why. Add in any new files to the zip. Always diff from the latest code if you can, to minimize the merge effort. Comment your code clearly. Uncommented code will likely be rejected, at least by me. Also, try and initial any changes performed. CVS keeps track of developers who make changes, but if a developer puts changes in for a non-developer, the initials will help delineate who was responsible for what.
Re: DEVS: Building from source
Here is some updated information.
Sourceforge has changed their CVS access slightly since the original writing of the above note. To make things convenient, for developer access I usually run a small script /bin/seq that looks like this:
If you are performing anonymous downloads, your script /bin/seq might look like this:
To inject the settings into my current shell, I run the script using:
That is a dot, then space, before the "seq". You need the dot.
Once that is done, you can extract the source code with:
Code:
cvs co myseq (to get the HEAD)
or
cvs co -r beta_1-20 myseq (to get the Beta v1.20 branch)
You should protect the DLL files in the client folder. The C# Visual Express tool defaults to deleting these files during any clean or rebuild operation. This is fixed in Service Pack 1 of Visual C# Express 2005, but it may be better to protect them by simply:
Code:
cd myseq/client
chmod -w+x *.dll *.DLL
You can also use commands like:
Code:
cvs status -> (gets the status of any file)
cvs update -> (updates the file to the latest)
cvs commit -> (commits the changed file to the repository)
cvs log -> (shows a log history of a file)
For more information: http://sourceforge.net/cvs/?group_id=10131
Note: To use all of this, you need to install Cygwin.
