https://wiki.secondlife.com/w/api.php?action=feedcontributions&user=Brad+Linden&feedformat=atomSecond Life Wiki - User contributions [en]2024-03-29T09:28:38ZUser contributionsMediaWiki 1.36.1https://wiki.secondlife.com/w/index.php?title=User:Brad_Linden/Login_MFA&diff=1210671User:Brad Linden/Login MFA2022-04-22T00:57:27Z<p>Brad Linden: added info about MFAHash debug setting</p>
<hr />
<div><br />
== New Parameters ==<br />
Any viewer that does not supply these fields in its login requests will be interpreted as not supporting MFA features<br />
<br />
; "token"<br />
: The user's entered Time based One Time Password (TOTP) token. This should be the empty string for login attempts that are not responding to an MFA challenge.<br />
; "mfa_hash"<br />
: The saved hash value and timestamp from a previously successfully answered MFA challenge. This should be the empty string initially. <br />
<br />
<br />
== New Returned Fields ==<br />
; "mfa_hash"<br />
: The optional hash value and timestamp from a successfully answered MFA challenge. This should be saved in secure storage scoped to the user and current grid similar to how saved passwords are stored. Currently the timestamps expire after 30 days. Subsequent login attempts for the same user and grid combination should fill in this value in the "mfa_hash" parameter of the login request.<br />
<br />
== New Errors ==<br />
; login failure reason - mfa_challenge<br />
: A new failure reason that should be handled by displaying a prompt to enter the TOTP token, and retrying the login request with that value in the "token" parameter.<br />
; login failure message - LoginFailedAuthenticationMFARequired<br />
: message to be presented to the user when prompting for token, for example:<br />
To continue logging in, enter a new token from your multifactor authentication app. If you feel this is an error, please contact support@secondlife.com<br />
; updated login failure message - LoginFailedAuthenticationFailed<br />
: new login failure request similar to password failure request. when mfa is required this indicates that either the password or TOTP token entered was not correct. For example:<br />
Sorry! We couldn't log you in.<br />
Please check to make sure you entered the right<br />
* Username (like bobsmith12 or steller.sunshine)<br />
* Password<br />
* Second Factor Token (if enabled)<br />
Also, please make sure your Caps Lock key is off.<br />
<br />
== New Debug Settings ==<br />
; "MFAHash" - string<br />
: This setting overrides the mfa_hash value stored for testing purposes. It is applied at login time, and will overwrite any saved mfa_hash value for the account that is logging in. This is typically used to set the mfa_hash value to "0" or some other value that is known to be invalid in order to force a new token challenge from the login server. It is non-persistent as a debug setting, but affects how the encrypted storage for the mfa_hash value is persisted. It must be set from the command line or from the Debug menu prior to logging in.</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=User_talk:Brad_Linden/Login_MFA&diff=1210438User talk:Brad Linden/Login MFA2022-02-18T01:22:50Z<p>Brad Linden: reply to questions</p>
<hr />
<div>Greetings Brad. I am backporting the MFA support to my viewer (the Cool VL Viewer) which, being a v1 viewer, does things differently to LL's viewer and TPVs based on it.<br />
<br />
Nothing difficult (*), but I'd like to make sanity checks in my code for the MFA hash I will store (in an LLXORCipher'ed and LLBase64-encoded form) in the user per-account settings (no LLSecAPIHandler in my viewer, and not planing/wanting to backport it). The sanity check is especially useful when retrieving the stored ciphered/encoded hash and decoding/deciphering it.<br />
<br />
I therefore need to know whether the MFA hash got a fixed size or not, and if yes, what size it is; is it a MD5 or SHA1 hash, for example ?<br />
<br />
So, if you could add details to the API specs about it, it would be great. :-)<br />
<br />
Thank you in advance !<br />
<br />
(*) If we except the fact that I do not own a smartphone and will not be able to even test my code !... Could we please get (at least on Aditi, for example) simple (plain text) email-based MFA so that viewer developers (I know that at least NiranV is in the same case as myself) can test the feature with their implementation without the need for a smartphone or any other third party device/application ?<br />
<br />
<br />
:Greetings Henri, thanks for your time and questions. Sorry I didn't get back to you sooner.<br />
:# I don't want to add these details to the API spec. These should be treated as implementation details, but for the purposes of sanity checking, you can inspect the mfa_hash value. The current implementation of the mfa_hash is the concatenation of an ISO-8601 timestamp (for expiration of this hash value) and a hex encoded HMAC-SHA-512 value as output by an [https://datatracker.ietf.org/doc/html/rfc6238 RFC6238] implementation of TOTP, with a comma separating them. I think the timestamp can be up to 27 or so characters, and the hex HMAC-SHA-512 will be 64 characters so that adds up to 92 characters of text. Naturally this is subject to change if we add more authentication options beyond RFC6238 TOTP protocol.<br />
:# I believe our QA engineers have had some success using the [https://pyauth.github.io/pyotp/ PyOTP] library for implementing an authenticator for testing without a closed smartphone application. I don't know the details myself, but I would recommend investigating that if it suits your needs.<br />
:Hope this helps, [[User:Brad Linden|Brad Linden]] ([[User talk:Brad Linden|talk]]) 17:22, 17 February 2022 (PST)</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=User:Brad_Linden/Login_MFA&diff=1210430User:Brad Linden/Login MFA2022-02-16T19:23:18Z<p>Brad Linden: </p>
<hr />
<div><br />
== New Parameters ==<br />
Any viewer that does not supply these fields in its login requests will be interpreted as not supporting MFA features<br />
<br />
; "token"<br />
: The user's entered Time based One Time Password (TOTP) token. This should be the empty string for login attempts that are not responding to an MFA challenge.<br />
; "mfa_hash"<br />
: The saved hash value and timestamp from a previously successfully answered MFA challenge. This should be the empty string initially. <br />
<br />
<br />
== New Returned Fields ==<br />
; "mfa_hash"<br />
: The optional hash value and timestamp from a successfully answered MFA challenge. This should be saved in secure storage scoped to the user and current grid similar to how saved passwords are stored. Currently the timestamps expire after 30 days. Subsequent login attempts for the same user and grid combination should fill in this value in the "mfa_hash" parameter of the login request.<br />
<br />
== New Errors ==<br />
; login failure reason - mfa_challenge<br />
: A new failure reason that should be handled by displaying a prompt to enter the TOTP token, and retrying the login request with that value in the "token" parameter.<br />
; login failure message - LoginFailedAuthenticationMFARequired<br />
: message to be presented to the user when prompting for token, for example:<br />
To continue logging in, enter a new token from your multifactor authentication app. If you feel this is an error, please contact support@secondlife.com<br />
; updated login failure message - LoginFailedAuthenticationFailed<br />
: new login failure request similar to password failure request. when mfa is required this indicates that either the password or TOTP token entered was not correct. For example:<br />
Sorry! We couldn't log you in.<br />
Please check to make sure you entered the right<br />
* Username (like bobsmith12 or steller.sunshine)<br />
* Password<br />
* Second Factor Token (if enabled)<br />
Also, please make sure your Caps Lock key is off.</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=User:Brad_Linden/Login_MFA&diff=1210418User:Brad Linden/Login MFA2022-02-04T19:27:17Z<p>Brad Linden: </p>
<hr />
<div><br />
== New Parameters ==<br />
Any viewer that does not supply these fields in its login requests will be interpreted as not supporting MFA features<br />
<br />
; "token"<br />
: The user's entered Time based One Time Password (TOTP) token. This should be the empty string for login attempts that are not responding to an MFA challenge.<br />
; "mfa_hash"<br />
: The saved hash value and timestamp from a previously successfully answered MFA challenge. This should be the empty string initially. <br />
<br />
<br />
== New Returned Fields ==<br />
; "mfa_hash"<br />
: The optional hash value and timestamp from a successfully answered MFA challenge. This should be saved in secure storage scoped to the user and current grid similar to how saved passwords are stored. Currently the timestamps expire after 30 days. Subsequent login attempts for the same user and grid combination should fill in this value in the "mfa_hash" parameter of the login request.<br />
<br />
== New Errors ==<br />
; login failure reason - mfa_challenge<br />
: A new failure reason that should be handled by displaying a prompt to enter the TOTP token, and retrying the login request with that value in the "token" parameter.<br />
; login failure message - LoginFailedAuthenticationMFARequired<br />
: message to be presented to the user when prompting for token, for example:<br />
To continue logging in, enter a new token from your multifactor authentication app. If you feel this is an error, please contact support@secondlife.com<br />
; login failure message - LoginFailedAuthenticationFailedMFA<br />
: new login failure request similar to password failure request. when mfa is required this indicates that either the password or TOTP token entered was not correct. For example:<br />
Sorry! We couldn't log you in.<br />
Please check to make sure you entered the right<br />
* Username (like bobsmith12 or steller.sunshine)<br />
* Password<br />
* Token<br />
Also, please make sure your Caps Lock key is off.</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=User:Brad_Linden/Login_MFA&diff=1210417User:Brad Linden/Login MFA2022-02-04T19:26:18Z<p>Brad Linden: </p>
<hr />
<div><br />
== New Parameters ==<br />
Any viewer that does not supply these fields will be interpreted as not supporting MFA features<br />
<br />
; "token"<br />
: The user's entered Time based One Time Password (TOTP) token. This should be the empty string for login attempts that are not responding to an MFA challenge.<br />
; "mfa_hash"<br />
: The saved hash value and timestamp from a previously successfully answered MFA challenge. This should be the empty string initially. <br />
<br />
<br />
== New Returned Fields ==<br />
; "mfa_hash"<br />
: The optional hash value and timestamp from a successfully answered MFA challenge. This should be saved in secure storage scoped to the user and current grid similar to how saved passwords are stored. Currently the timestamps expire after 30 days. Subsequent login attempts for the same user and grid combination should fill in this value in the "mfa_hash" parameter of the login request.<br />
<br />
== New Errors ==<br />
; login failure reason - mfa_challenge<br />
: A new failure reason that should be handled by displaying a prompt to enter the TOTP token, and retrying the login request with that value in the "token" parameter.<br />
; login failure message - LoginFailedAuthenticationMFARequired<br />
: message to be presented to the user when prompting for token, for example:<br />
To continue logging in, enter a new token from your multifactor authentication app. If you feel this is an error, please contact support@secondlife.com<br />
; login failure message - LoginFailedAuthenticationFailedMFA<br />
: new login failure request similar to password failure request. when mfa is required this indicates that either the password or TOTP token entered was not correct. For example:<br />
Sorry! We couldn't log you in.<br />
Please check to make sure you entered the right<br />
* Username (like bobsmith12 or steller.sunshine)<br />
* Password<br />
* Token<br />
Also, please make sure your Caps Lock key is off.</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=User:Brad_Linden/Login_MFA&diff=1210416User:Brad Linden/Login MFA2022-02-04T19:25:35Z<p>Brad Linden: </p>
<hr />
<div><br />
== New Parameters ==<br />
Any viewer that does not supply these fields will be interpreted as not supporting MFA features<br />
<br />
; "token"<br />
: The user's entered Time based One Time Password (TOTP) token. This should be the empty string for login attempts that are not responding to an MFA challenge.<br />
; "mfa_hash"<br />
: The saved hash value and timestamp from a previously successfully answered MFA challenge. This should be the empty string initially. <br />
<br />
<br />
== New Returned Fields ==<br />
; "mfa_hash"<br />
: The optional hash value and timestamp from a successfully answered MFA challenge. This should be saved in secure storage scoped to the user and current grid similar to how passwords ar be stored. Currently the timestamps expire after 30 days. Subsequent login attempts for the same user and grid combination should fill in this value in the "mfa_hash" parameter of the login request.<br />
<br />
== New Errors ==<br />
; login failure reason - mfa_challenge<br />
: A new failure reason that should be handled by displaying a prompt to enter the TOTP token, and retrying the login request with that value in the "token" parameter.<br />
; login failure message - LoginFailedAuthenticationMFARequired<br />
: message to be presented to the user when prompting for token, for example:<br />
To continue logging in, enter a new token from your multifactor authentication app. If you feel this is an error, please contact support@secondlife.com<br />
; login failure message - LoginFailedAuthenticationFailedMFA<br />
: new login failure request similar to password failure request. when mfa is required this indicates that either the password or TOTP token entered was not correct. For example:<br />
Sorry! We couldn't log you in.<br />
Please check to make sure you entered the right<br />
* Username (like bobsmith12 or steller.sunshine)<br />
* Password<br />
* Token<br />
Also, please make sure your Caps Lock key is off.</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=User:Brad_Linden/Login_MFA&diff=1210415User:Brad Linden/Login MFA2022-02-04T19:24:59Z<p>Brad Linden: initial spec for viewer MFA feature requirements</p>
<hr />
<div><br />
== New Parameters ==<br />
; "token"<br />
: The user's entered Time based One Time Password (TOTP) token. This should be the empty string for login attempts that are not responding to an MFA challenge.<br />
; "mfa_hash"<br />
: The saved hash value and timestamp from a previously successfully answered MFA challenge. This should be the empty string initially. <br />
<br />
<br />
Any viewer that does not supply these fields will be interpreted as not supporting MFA features<br />
<br />
== New Returned Fields ==<br />
; "mfa_hash"<br />
: The optional hash value and timestamp from a successfully answered MFA challenge. This should be saved in secure storage scoped to the user and current grid similar to how passwords ar be stored. Currently the timestamps expire after 30 days. Subsequent login attempts for the same user and grid combination should fill in this value in the "mfa_hash" parameter of the login request.<br />
<br />
== New Errors ==<br />
; login failure reason - mfa_challenge<br />
: A new failure reason that should be handled by displaying a prompt to enter the TOTP token, and retrying the login request with that value in the "token" parameter.<br />
; login failure message - LoginFailedAuthenticationMFARequired<br />
: message to be presented to the user when prompting for token, for example:<br />
To continue logging in, enter a new token from your multifactor authentication app. If you feel this is an error, please contact support@secondlife.com<br />
; login failure message - LoginFailedAuthenticationFailedMFA<br />
: new login failure request similar to password failure request. when mfa is required this indicates that either the password or TOTP token entered was not correct. For example:<br />
Sorry! We couldn't log you in.<br />
Please check to make sure you entered the right<br />
* Username (like bobsmith12 or steller.sunshine)<br />
* Password<br />
* Token<br />
Also, please make sure your Caps Lock key is off.</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild&diff=1138899Autobuild2011-03-31T22:56:44Z<p>Brad Linden: /* Contributing to Autobuild */</p>
<hr />
<div>{{Autobuild Nav}}<br />
<br />
== Overview ==<br />
Autobuild is a framework for maintaining and building libraries. It acts as director providing a common interface to build and package libraries, but it is not a build system like make or cmake. You will still need platform-specific make, cmake, or project files to configure and build your library. Autobuild will, however, allow you invoke these commands and package the product with a common interface. <br />
<br />
{{KBcaution|Linden Lab Autobuild is not the same as or derived from [http://josefsson.org/autobuild/ GNU Autobuild], but they are similar enough to cause confusion.}}<br />
<br />
For Linden old hands: Autobuild is designed as a replacement for the old [https://svn.lindenlab.com/svn/lindenlib/trunk lindenlib] policies; doing the right thing so you don't have to.<br />
<br />
== Getting Autobuild ==<br />
<br />
Autobuild is available as a PyPI package:<br />
<br />
[http://pypi.python.org/pypi/setuptools easy_install] autobuild<br />
<br />
or<br />
<br />
[http://pypi.python.org/pypi/pip pip] install autobuild<br />
<br />
of if you don't have pip or easy_install<br />
<br />
hg clone http://hg.secondlife.com/autobuild<br />
cd autobuild<br />
python setup.py install<br />
<br />
You may need administrative privilege on your system to install into system command directories.<br />
<br />
{{KBnote|If you are using Cygwin on Windows, you must also add your Python scripts directory (for example <code>C:/Program Files/python26/Scripts</code>) to your PATH. If you have further problems, please see [[Autobuild/Cygwin]]}}<br />
<br />
{{KBtip|If you do not have administrative privilege on your system, or for any reason you wish to avoid adding autobuild into system-level Python or command directories, you can use [http://www.virtualenv.org/en/latest/index.html virtualenv], e.g.:<br />
<br />
mkdir ~/virtualenvs # or any directory for your Python-package environments<br />
VENV{{=}}~/virtualenvs/autobuild<br />
virtualenv "$VENV"<br />
. "$VENV/bin/activate"<br />
<br />
Then your <code>pip install autobuild</code> command will install autobuild under <code>$VENV</code> instead of into system directories. (Note that this <code>pip install</code> command will work either way. If you have an active virtualenv, it will install into the virtualenv; if not it will attempt to install into system directories.)<br />
}} <!-- end pip/virtualenv tip --><br />
<br />
== Running Autobuild == <br />
Usage:<br />
{{Syntax|autobuild ''options'' ''sub-command''<br />
}}<br />
<br />
Supply zero or more options, and one sub-command.<br />
<br />
'''Options''':<br />
{|border="1" class="lltable"<br />
<br />
|--<br />
! Option<br />
! Description <br />
<br />
|--<br />
| --debug<br />
| Display debug information<br />
<br />
|--<br />
| --dry-run<br />
| Run tool in dry run mode if available<br />
<br />
|--<br />
| --help&nbsp;[''command'']<br />
| Find all valid Autobuild tools and show help<br />
<br />
|--<br />
| --quiet<br />
| Display minimal output<br />
<br />
|--<br />
| --verbose<br />
| Display verbose output<br />
<br />
|--<br />
| -V, --version<br />
| Show version information<br />
<br />
|}<br />
<br />
'''Sub-commands'''<br />
{| class=lltable border=1<br />
|--<br />
! Sub-command<br />
! Description<br />
|--<br />
| [[autobuild build|build]]<br />
| Build platform targets.<br />
|--<br />
| [[autobuild configure|configure]]<br />
| Configure platform targets.<br />
|--<br />
| [[autobuild edit|edit]]<br />
| Manage build and package configuration.<br />
|--<br />
| [[autobuild install|install]]<br />
| Fetch and install package archives.<br />
|--<br />
| [[autobuild installables|installables]]<br />
| Manipulate installable package entries in the autobuild configuration.<br />
|--<br />
| [[autobuild manifest|manifest]]<br />
| Manipulate manifest entries to the autobuild configuration.<br />
|--<br />
| [[autobuild package|package]]<br />
| Create an archive of build output.<br />
|--<br />
| [[autobuild print|print]]<br />
| Print configuration.<br />
|--<br />
| [[autobuild source_environment|source_environment]]<br />
| Print the shell environment Autobuild-based build scripts to use (by calling 'eval').<br />
|--<br />
| [[autobuild uninstall|uninstall]]<br />
| Uninstall package archives.<br />
|--<br />
| [[autobuild upload|upload]]<br />
| Upload tool for autobuild <br />
|}<br />
<br />
===Background and Tutorials===<br />
<br />
; [[Autobuild How To]]<br />
: A tutorial introduction to using autobuild<br />
; [[Autobuild Lexicon]]<br />
: A list of terms and how they are used in the context of autobuild<br />
; [[Autobuild Package Layout]]<br />
: Describes the standard directory tree for packages managed with autobuild<br />
; [[Autobuild Quick Start]]<br />
: A basic walkthrough of how to add autobuild management to an existing software project<br />
; [[Autobuild Class Model]]<br />
: Describes the fundamental objects in the autobuild design and the relationships between them.<br />
; [[Autobuild Package Examples|Autobuild Examples]]<br />
: Links to packages built with autobuild.<br />
; [[Build Script Anatomy]]<br />
: An annotated build script typical of those used to build third party libraries.<br />
; [[Autobuild Shell Functions]]<br />
: A description of all shell functions provided by Autobuild for use in build scripts.<br />
<br />
== Contributing to Autobuild ==<br />
<br />
Autobuild is open source. Improvements are most welcome. <br />
<br />
* Discussion of and help with Autobuild are available on the [https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev opensource-dev mailing list] and the [irc://irc.freenode.org/%23opensl #opensl channel on the freenode.org IRC network].<br />
* Bug reports and feature suggestions are tracked in the [https://jira.secondlife.com/browse/OPEN Open Development project on jira.secondlife.com].<br />
** Suggested patches for issues from the jira are reviewed on our [https://codereview.secondlife.com code review system] (see [[Code Review Tool|the documentation on how to use it]]).<br />
** Testing procedures for patch submissions are documented here: [[Autobuild/Integration]]<br />
<br />
[[Category:Autobuild]] [[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Cygwin&diff=1138898Autobuild/Cygwin2011-03-31T22:54:40Z<p>Brad Linden: typo</p>
<hr />
<div>Previously, Windows users with a "native" Python install were advised to avoid the Cygwin shell like the plague.<br />
<br />
However, things should be better [http://hg.secondlife.com/autobuild/changeset/f6c25ce56f9f now]. We are now using the [http://packages.python.org/distribute/ distribute] extension of the python setuptools, so the autobuild application installed should now be equally executable by any shell.<br />
<br />
If you want to run autobuild directly from a mercurial checkout without installing, we still provide the autobuild.cmd wrapper. It can be used by executing the following:<br />
ln -s /path/to/autobuild/checkout/bin/autobuild.cmd ~/bin/autobuild<br />
export PATH="$PATH:~/bin/"<br />
<br />
However, as this is trickier to set up and more error prone, it is not the primary method that we recommend in [[Autobuild#Getting_Autobuild]].</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Cygwin&diff=1138897Autobuild/Cygwin2011-03-31T22:54:07Z<p>Brad Linden: </p>
<hr />
<div>Previously, Windows users with a "native" Python install were advised to avoid the Cygwin shell like the plague.<br />
<br />
However, things should be better [http://hg.secondlife.com/autobuild/changeset/f6c25ce56f9f now]. We are now using the [http://packages.python.org/distribute/ distribute] extension of the python setuptools, so the autobuild application installed should now be equally executable by any shell.<br />
<br />
If you want to run autobuild directly from a mercurial checkout without installing, we still provide the autobuild.cmd wrapper. It can be used by executing the following:<br />
ln -s /path/to/autobuild/checkout/bin/autobuild.cmd ~/bin/autobuild<br />
export PATH="$PATH:~/bin/<br />
<br />
However, as this is trickier to set up and more error prone, it is not the primary method that we recommend in [[Autobuild#Getting_Autobuild]].</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Cygwin&diff=1138896Autobuild/Cygwin2011-03-31T22:52:46Z<p>Brad Linden: documented cygwin specific issues installing autobuild</p>
<hr />
<div>Previously, Windows users with a "native" Python install were advised to avoid the Cygwin shell like the plague.<br />
<br />
However, things should be better [http://hg.secondlife.com/autobuild/changeset/f6c25ce56f9f now]. We are now using the [http://packages.python.org/distribute/ distribute] extension of the python setuptools, so the autobuild application installed should now be equally executable by any shell.<br />
<br />
If you want to run autobuild directly from a mercurial checkout without installing, we still provide the autobuild.cmd wrapper. It can be used by executing the following:<br />
ln -s /path/to/autobuild/checkout/bin/autobuild.cmd ~/bin/autobuild<br />
export PATH="$PATH:~/bin/<br />
<br />
However, as this is trickier to set up and more error prone, it is not the primary method that we recommend.</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild&diff=1138895Autobuild2011-03-31T22:52:38Z<p>Brad Linden: /* Getting Autobuild */ updated cygwin install info and documented running setup.py manually</p>
<hr />
<div>{{Autobuild Nav}}<br />
<br />
== Overview ==<br />
Autobuild is a framework for maintaining and building libraries. It acts as director providing a common interface to build and package libraries, but it is not a build system like make or cmake. You will still need platform-specific make, cmake, or project files to configure and build your library. Autobuild will, however, allow you invoke these commands and package the product with a common interface. <br />
<br />
{{KBcaution|Linden Lab Autobuild is not the same as or derived from [http://josefsson.org/autobuild/ GNU Autobuild], but they are similar enough to cause confusion.}}<br />
<br />
For Linden old hands: Autobuild is designed as a replacement for the old [https://svn.lindenlab.com/svn/lindenlib/trunk lindenlib] policies; doing the right thing so you don't have to.<br />
<br />
== Getting Autobuild ==<br />
<br />
Autobuild is available as a PyPI package:<br />
<br />
[http://pypi.python.org/pypi/setuptools easy_install] autobuild<br />
<br />
or<br />
<br />
[http://pypi.python.org/pypi/pip pip] install autobuild<br />
<br />
of if you don't have pip or easy_install<br />
<br />
hg clone http://hg.secondlife.com/autobuild<br />
cd autobuild<br />
python setup.py install<br />
<br />
You may need administrative privilege on your system to install into system command directories.<br />
<br />
{{KBnote|If you are using Cygwin on Windows, you must also add your Python scripts directory (for example <code>C:/Program Files/python26/Scripts</code>) to your PATH. If you have further problems, please see [[Autobuild/Cygwin]]}}<br />
<br />
{{KBtip|If you do not have administrative privilege on your system, or for any reason you wish to avoid adding autobuild into system-level Python or command directories, you can use [http://www.virtualenv.org/en/latest/index.html virtualenv], e.g.:<br />
<br />
mkdir ~/virtualenvs # or any directory for your Python-package environments<br />
VENV{{=}}~/virtualenvs/autobuild<br />
virtualenv "$VENV"<br />
. "$VENV/bin/activate"<br />
<br />
Then your <code>pip install autobuild</code> command will install autobuild under <code>$VENV</code> instead of into system directories. (Note that this <code>pip install</code> command will work either way. If you have an active virtualenv, it will install into the virtualenv; if not it will attempt to install into system directories.)<br />
}} <!-- end pip/virtualenv tip --><br />
<br />
== Running Autobuild == <br />
Usage:<br />
{{Syntax|autobuild ''options'' ''sub-command''<br />
}}<br />
<br />
Supply zero or more options, and one sub-command.<br />
<br />
'''Options''':<br />
{|border="1" class="lltable"<br />
<br />
|--<br />
! Option<br />
! Description <br />
<br />
|--<br />
| --debug<br />
| Display debug information<br />
<br />
|--<br />
| --dry-run<br />
| Run tool in dry run mode if available<br />
<br />
|--<br />
| --help&nbsp;[''command'']<br />
| Find all valid Autobuild tools and show help<br />
<br />
|--<br />
| --quiet<br />
| Display minimal output<br />
<br />
|--<br />
| --verbose<br />
| Display verbose output<br />
<br />
|--<br />
| -V, --version<br />
| Show version information<br />
<br />
|}<br />
<br />
'''Sub-commands'''<br />
{| class=lltable border=1<br />
|--<br />
! Sub-command<br />
! Description<br />
|--<br />
| [[autobuild build|build]]<br />
| Build platform targets.<br />
|--<br />
| [[autobuild configure|configure]]<br />
| Configure platform targets.<br />
|--<br />
| [[autobuild edit|edit]]<br />
| Manage build and package configuration.<br />
|--<br />
| [[autobuild install|install]]<br />
| Fetch and install package archives.<br />
|--<br />
| [[autobuild installables|installables]]<br />
| Manipulate installable package entries in the autobuild configuration.<br />
|--<br />
| [[autobuild manifest|manifest]]<br />
| Manipulate manifest entries to the autobuild configuration.<br />
|--<br />
| [[autobuild package|package]]<br />
| Create an archive of build output.<br />
|--<br />
| [[autobuild print|print]]<br />
| Print configuration.<br />
|--<br />
| [[autobuild source_environment|source_environment]]<br />
| Print the shell environment Autobuild-based build scripts to use (by calling 'eval').<br />
|--<br />
| [[autobuild uninstall|uninstall]]<br />
| Uninstall package archives.<br />
|--<br />
| [[autobuild upload|upload]]<br />
| Upload tool for autobuild <br />
|}<br />
<br />
===Background and Tutorials===<br />
<br />
; [[Autobuild How To]]<br />
: A tutorial introduction to using autobuild<br />
; [[Autobuild Lexicon]]<br />
: A list of terms and how they are used in the context of autobuild<br />
; [[Autobuild Package Layout]]<br />
: Describes the standard directory tree for packages managed with autobuild<br />
; [[Autobuild Quick Start]]<br />
: A basic walkthrough of how to add autobuild management to an existing software project<br />
; [[Autobuild Class Model]]<br />
: Describes the fundamental objects in the autobuild design and the relationships between them.<br />
; [[Autobuild Package Examples|Autobuild Examples]]<br />
: Links to packages built with autobuild.<br />
; [[Build Script Anatomy]]<br />
: An annotated build script typical of those used to build third party libraries.<br />
; [[Autobuild Shell Functions]]<br />
: A description of all shell functions provided by Autobuild for use in build scripts.<br />
<br />
== Contributing to Autobuild ==<br />
<br />
Autobuild is open source. Improvements are most welcome. <br />
<br />
* Discussion of and help with Autobuild are available on the [https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev opensource-dev mailing list] and the [irc://irc.freenode.org/%23opensl #opensl channel on the freenode.org IRC network].<br />
* Bug reports and feature suggestions are tracked in the [https://jira.secondlife.com/browse/OPEN Open Development project on jira.secondlife.com].<br />
** Suggested patches for issues from the jira are reviewed on our [https://codereview.secondlife.com code review system] (see [[Code Review Tool|the documentation on how to use it]]).<br />
<br />
[[Category:Autobuild]] [[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Integration&diff=1138894Autobuild/Integration2011-03-31T22:13:37Z<p>Brad Linden: initial draft of testing procedures</p>
<hr />
<div>{{Note|This page is a work in progress, none of the procedures documented here are finalized yet. [[User:Brad Linden|Brad Linden]] 15:13, 31 March 2011 (PDT)}}<br />
<br />
This page describes how to make changes to [[Autobuild]] and get it tested and integrated for others to use. It's intended to be analogous to the process described at [[How To Submit A Viewer Change]] but somewhat simplified.<br />
<br />
== Testing Requirements ==<br />
<br />
=== Unit Tests ===<br />
<br />
Tests are under [http://hg.secondlife.com/autobuild/src/tip/autobuild/tests/ autobuild/tests]<br />
You can run them by running <tt>nosetests -v</tt> from the top of the autobuild source tree. (see [http://somethingaboutorange.com/mrl/projects/nose/1.0.0/ nose documentation]) <br />
<br />
=== Integration Tests ===<br />
<br />
We have teamcity running a test build against a staging repo: [http://bitbucket.org/brad_linden/autobuild-integration autobuild-integration]. So changes should be pushed there first for testing before getting promoted to http://hg.secondlife.com/autobuild .<br />
<br />
You need to check out 4 repos side-by-side to run the tests here:<br />
*[http://hg.secondlife.com/buildscripts buildscripts] (note this is currently broken, as default-autobuild.sh is missing for now)<br />
*autobuild (cloned from your branch with your new changes to test)<br />
*[http://bitbucket.org/brad_linden/autobuild-testscript autobuild-testscript]<br />
*[http://bitbucket.org/lindenlab/3p-curl 3p-curl]<br />
<br />
Then run <tt>autobuild-testscript/build.sh</tt>. You can also test against additional packages by checking them out alongside 3p-curl and setting the test_pkgs environment variable either manually or in <tt>autobuild-testscript/BuildParams</tt></div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Crash_logs&diff=1138485Crash logs2011-03-25T19:02:33Z<p>Brad Linden: /* Where do I find the logs? */ corrected incorrectly named SecondLifeCrashReport.log</p>
<hr />
<div><noinclude>{{KBmaster}}</noinclude><br />
<br />
== What are diagnostic logs? ==<br />
<br />
Diagnostic logs, including crash logs, are a very important tool for debugging Second Life Viewer problems; they allow a developer to try to fix a bug that they've never personally witnessed.<br />
<br />
Sometimes, our [http://secondlife.com/support Support] team will ask you to provide diagnostic logs while helping you with a support ticket. Support may ask you to provide specific logs; preferably, you can attach them to a support ticket, or if the contents are shorter, you can open them up in a text editor and copy-and-paste them into your ticket. If you're not sure, ask Support to clarify.<br />
<br />
The Viewer can automatically submit crash logs to Linden Lab when the Viewer crashes, but external developers can't see them publicly. If you'd like the broader community to help find the bug that caused Second Life to crash on your computer, you can report the bug on the [[Issue Tracker]] and attach your crash logs.<br />
<br />
== Where do I find the logs? ==<br />
<br />
You'll need to locate the <code>SecondLife</code> folder which contains the <code>logs</code> folder, and its location depends on your platform. '''[[User settings|See the "User settings" page]]''' for instructions.<br />
<br />
In addition, platform specifics:<br />
<br />
=== Windows 7 and Vista ===<br />
<br />
{{KBtip|If you have problems finding this folder, try [http://www.voidtools.com/ Everything], a handy tool that searches ''everything'' on your hard drive by name.}}<br />
<br />
The folder is usually located at <code>C:\Users\<username>\AppData\Roaming</code>. If you install Second Life in a different location, the path is different. In any case, to get to the right place:<br />
<br />
# In Windows Explorer, click the '''[http://en.wikipedia.org/wiki/Start_button Start Button]'''.<br />
# In the search field (in Windows 7, it's labeled "Search programs and files" and in Windows Vista, it's labeled "Start Search"), type <code>%appdata%</code> and press {{K|Enter}}.<br />
# In the window that appears, open the <code>SecondLife</code> folder.<br />
# see the logs folder for SecondLife.log, SecondLifeCrashReport.log and stack_trace.log<br />
<br />
<br />
=== Windows XP ===<br />
<br />
The folder is usually located at <code>C:\Documents and Settings\<username>\Application Data\SecondLife</code>. If you install Second Life in a different location, the path is different. To get to the right place:<br />
<br />
# In Windows Explorer, click '''[http://en.wikipedia.org/wiki/Start_button Start button]'''.<br />
# Click '''Run'''.<br />
# In the Run window, type <code>%appdata%</code> and click '''OK'''.<br />
#: [[File:Windows_XP_appdata.png]]<br />
# In the window that appears, open the <code>SecondLife</code> folder.<br />
# see the logs folder for SecondLife.log, SecondLifeCrashReport.log and stack_trace.log<br />
<br />
<br />
=== Mac ===<br />
<br />
In addition to the Viewer's own crash reporting, there's also:<br />
<br />
* A general Mac OS X tool called [http://en.wikipedia.org/wiki/Crash_Reporter_%28Mac_OS_X%29 Crash Reporter]. [http://developer.apple.com/technotes/tn2004/tn2123.html More technical details.]<br />
* A [http://en.wikipedia.org/wiki/System_Profiler_%28Apple%29 System Profiler] report, which contains all of the necessary data about your computer and the hardware inside of it. This is useful for Linden Lab to group problems with similar hardware.<br />
*# In the Finder, choose '''Apple''' menu > '''About This Mac'''.<br />
*# Click the '''More Info''' button to open the System Profiler.<br />
*# In the System Profile, choose '''File''' > '''Save'''. Give the file a unique name so you can find it later, then attach it to your [[Issue Tracker]] bug report. Also [http://developer.apple.com/bugreporter/bugbestpractices.html see "Bug Reporting Best Practices" from Apple].<br />
<br />
<br />
=== Linux ===<br />
<br />
The folder is located at <code>~/.secondlife</code> - it's a hidden folder (the folder name begins with a dot) and it's inside the user home folder. To get here:<br />
<br />
# Open your file manager<br />
# go to your home folder<br />
# if needed, enable "Show Hidden Files and Directories" or a similar option in your file manager<br />
# open the <code>.secondlife</code> folder<br />
# see the logs folder for SecondLife.log, SecondLifeCrashReport.log and stack_trace.log<br />
<br />
<br />
[[Category:Error Messages]]<br />
[[Category:Troubleshooting]]<br />
[[Category:Technical Issue]]<br />
[[Category:General Help]]<br />
[[Category:General Second Life Software Information]]<br />
[[Category:Knowledge Base]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild_Shell_Functions&diff=1136768Autobuild Shell Functions2011-03-05T02:13:12Z<p>Brad Linden: </p>
<hr />
<div>Autobuild offers a set of shell functions for use in <tt>build-cmd.sh</tt> scripts which can be added to the environment by inserting the following line into any build script:<br />
<br />
eval "$("$AUTOBUILD" source_environment)"<br />
<br />
The exact shell code that is injected into your environment upon execution of this command [https://bitbucket.org/lindenlab/autobuild/src/tip/autobuild/autobuild_tool_source_environment.py is here].<br />
<br />
Shell functions provided by autobuild:<br />
:{|border="0" cellpadding="5" style="border-collapse: collapse; border-style: none;"<br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>pass</nowiki><br />
|<nowiki>Indicates build has succeeded</nowiki><br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>fail $comment</nowiki><br />
|<nowiki>Indicates build has failed, citing $comment in the output</nowiki><br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>fetch_archive $url $archive $md5</nowiki><br />
|<nowiki>Uses curl to download $archive from the $url and checks the downloaded file hash against the $md5 provided.</nowiki><br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>extract $file</nowiki><br />
| <nowiki>Extracts contents of an archive appropriate for the tar extension of $file.</nowiki><br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>calc_md5 $file</nowiki><br />
|<nowiki>Calculate the md5 of $file</nowiki><br />
<br />
|}<br />
<br />
<br />
Windows-only shell commands (Cygwin):<br />
:{|border="0" cellpadding="5" style="border-collapse: collapse; border-style: none;"<br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>build_vcproj $vcproj $config</nowiki><br />
|<nowiki>Launches a Visual Studio build of $vcproj, building configuration $config. If $USE_INCREDIBUILD is set, the same build is launched via BuildConsole, Incredibuild's command-line launcher.</nowiki><br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>build_sln $sln $config $project</nowiki><br />
|<nowiki>Launches a Visual Studio build using the solution file $sln, configuration $config, and specifying project $project. If $project is omitted, then the entire solution will be built.</nowiki><br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>load_vsvars</nowiki><br />
|<nowiki>Import Visual Studio paths, includes and libs into the shell environment</nowiki><br />
<br />
|}</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild&diff=1136749Autobuild2011-03-04T23:07:28Z<p>Brad Linden: /* Installing Autobuild */</p>
<hr />
<div>{{RightToc}}<br />
Autobuild is an in-house framework for maintaining and building libraries. It acts as director providing a common interface to build and package libraries, but it is not a build system like make or cmake. You will still need platform specific make, cmake, or project files to actually configure and build your library. Autobuild will, however, allow you invoke these commands and package the product with a common interface. (''for Linden old hands: Autobuild is designed as a replacement for the old [https://svn.lindenlab.com/svn/lindenlib/trunk lindenlib] policies, doing the right thing so you don't have to.'')<br />
<br />
{{KBcaution|Linden Lab Autobuild is not the same as or derived from [http://josefsson.org/autobuild/ GNU Autobuild], but they are similar enough to cause confusion.}}<br />
<br />
== Getting Autobuild ==<br />
<br />
Autobuild is available as a Mercurial repository:<br />
https://bitbucket.org/lindenlab/autobuild <br />
<br />
=== Installing Autobuild ===<br />
<br />
You can either run the autobuild command directly from the "bin" directory in a working copy of that repository, or install it as a normal python package by running <br />
python setup.py install<br />
from the top level directory of the working copy. You may need administrative privilege on your system to install into system command directories.<br />
{{KBnote|if you intend to run autobuild from a cygwin shell on windows, it is strongly recommended that you run <tt>python setup.py install</tt> rather than run it directly from the checkout. This is the most reliable way to ensure that cygwin paths get correctly translated to native windows paths for python. Then ensure that your python scripts directory (for example <tt>C:/Program Files/python26/Scripts</tt>) is in your PATH.}}<br />
<br />
== Running Autobuild == <br />
Usage:<br />
<nowiki>autobuild [-v] [--help [HELP]] [--dry-run] [--quiet] [--verbose]</nowiki><br />
<nowiki>[--debug]</nowiki><br />
<br />
<nowiki>{installables,configure,package,edit,upload,manifest,build,install,print,source_environment,uninstall}</nowiki><br />
<nowiki>...</nowiki><br />
<br />
Sub Commands:<br />
<br />
:;[[autobuild build]]<br />
::<nowiki>Builds platform targets.</nowiki><br />
:;[[autobuild configure]]<br />
::<nowiki>Configures platform targets.</nowiki><br />
:;[[autobuild edit]]<br />
::<nowiki>Manage build and package configuration.</nowiki><br />
:;[[autobuild install]]<br />
::<nowiki>Fetch and install package archives.</nowiki><br />
:;[[autobuild installables]]<br />
::<nowiki>Manipulate installable package entries in the autobuild configuration.</nowiki><br />
:;[[autobuild manifest]]<br />
::<nowiki>Manipulate manifest entries to the autobuild configuration.</nowiki><br />
:;[[autobuild package]]<br />
::<nowiki>Creates an archive of build output.</nowiki><br />
:;[[autobuild print]]<br />
::<nowiki>Print configuration.</nowiki><br />
:;[[autobuild source_environment]]<br />
::<nowiki>Prints out the shell environment Autobuild-based buildscripts to use (by calling 'eval').</nowiki><br />
:;[[autobuild uninstall]]<br />
::<nowiki>Uninstall package archives.</nowiki><br />
:;[[autobuild upload]]<br />
::<nowiki>upload tool for autobuild </nowiki><br />
<br />
Options:<br />
:{|border="0" cellpadding="5" style="border-collapse: collapse; border-style: none;"<br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>-v, --version</nowiki><br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>--help&nbsp;[HELP]</nowiki><br />
|<nowiki>find all valid Autobuild Tools and show help</nowiki><br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>--dry-run</nowiki><br />
|<nowiki>run tool in dry run mode if available</nowiki><br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>--quiet</nowiki><br />
|<nowiki>minimal output</nowiki><br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>--verbose</nowiki><br />
|<nowiki>verbose output</nowiki><br />
<br />
|- style="vertical-align: top;"<br />
|<nowiki>--debug</nowiki><br />
<br />
|}<br />
<br />
===Background and Tutorials===<br />
<br />
; [[Autobuild How To]]<br />
: A tutorial introduction to using autobuild<br />
; [[Autobuild Lexicon]]<br />
: A list of terms and how they are used in the context of autobuild<br />
; [[Autobuild Package Layout]]<br />
: Describes the standard directory tree for packages managed with autobuild<br />
; [[Autobuild Quick Start]]<br />
: A basic walkthrough of how to add autobuild management to an existing software project<br />
; [[Autobuild Class Model]]<br />
: Describes the fundamental objects in the autobuild design and the relationships between them.<br />
; [[Autobuild Package Examples|Autobuild Examples]]<br />
: Links to packages built with autobuild.<br />
; [[Build Script Anatomy]]<br />
: An annotated build script typical of those used to build third party libraries.<br />
<br />
== Contributing to Autobuild ==<br />
<br />
Autobuild is open source. Improvements are most welcome. <br />
<br />
* Discussion of and help with Autobuild are available on the [https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev opensource-dev mailing list] and the [irc://irc.freenode.org/%23opensl #opensl channel on the freenode.org IRC network].<br />
* Bug reports and feature suggestions are tracked in the [https://jira.secondlife.com/browse/OPEN Open Development project on jira.secondlife.com].<br />
** Suggested patches for issues from the jira are reviewed on our [https://codereview.secondlife.com code review system] (see [[Code Review Tool|the documentation on how to use it]]).<br />
<br />
[[Category:Autobuild]] [[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Quick_Start&diff=1134744Autobuild/Quick Start2011-02-18T17:48:08Z<p>Brad Linden: /* What haven't we done */</p>
<hr />
<div>{{RightToc}}<br />
<br />
When creating a new autobuild package of a library, it can be unclear where to start. [[Autobuild How To]] can be a little intimidating. We're packaging a simple third party library just like all the rest of ours, so we don't need to use autobuild in it's full generality. We can skip some steps and share script fragments with other library packages.<br />
<br />
Autobuild is largely self documenting. You can access help via the commands <tt>autobuild --help</tt> or <tt>autobuild &lt;subcommand&gt; --help</tt>, for example <tt>autobuild edit --help</tt>. If the help text is unclear, please file a bug.<br />
<br />
Here's a crash course:<br />
<br />
==What will we be doing==<br />
<br />
Your packaging efforts will mostly consist of creating or modifying 2 files: autobuild.xml, and build-cmd.sh<br />
<br />
;autobuild.xml : Autobuild package definition metadata. For now, what you should focus on "This specifies the actual shell commands that autobuild should execute for each step." You should modify this file using the '<tt>autobuild edit</tt>' command. Editing it by hand will lead to problems.<br />
;build-cmd.sh : the shell script that we are going to specify as the build command in autobuild.xml we've encapsulated a lot of the complexity within this script for our third party libraries, so we can just clone it from an existing library and customize it for our package.<br />
<br />
==What do we do==<br />
Get autobuild:<br />
hg clone http://hg.secondlife.com/autobuild<br />
cd autobuild/bin<br />
export PATH="$PATH:$(pwd)"<br />
cd ../..<br />
<br />
Copy the skeleton from an existing package.<br />
hg init hello<br />
cd hello<br />
curl -OL http://hg.secondlife.com/3p-zlib/raw/tip/BuildParams<br />
curl -OL http://hg.secondlife.com/3p-zlib/raw/tip/build-cmd.sh<br />
chmod +x build-cmd.sh<br />
curl -OL http://hg.secondlife.com/3p-zlib/raw/tip/.hgignore<br />
hg add BuildParams build-cmd.sh .hgignore<br />
<br />
Now you'll need to edit build-cmd.sh and customize it for your package in our case, [http://www.gnu.org/software/hello/ GNU Hello]. Mostly this is just a search and replace (replace occurrences of curl and CURL with the name or your package). For example, the sed search & replace commands would be <tt>s/curl/hello/g</tt> and <tt>s/CURL/HELLO/g</tt> in this case. You'll likely also need to update the version number variables to match your package's version.<br />
<br />
Additionally you'll need to update the 3 sections under the case statement with any platform specific quirks for how to build your package natively. Darwin and Linux can be pretty standardized, but under windows there are a lot of different ways to build your package. Most of these have been worked through already for one package or another, so talk to a team [[Chopper]] member or scan [[Autobuild/Package Index]] if you need examples to imitate.<br />
<br />
<br />
In the end, you should come up with something like this [[Autobuild/Quick_Start/build-cmd.sh|example build-cmd.sh]].<br />
<br />
You'll need some information about your package from the upstream package distributor for filling in some of the prompts. For example you should copy the copyright string and license info verbatim from the upstream distributor. Additionally we should always write our build script to copy the text of the license into <tt>LICENSES/&lt;package name&gt;.txt</tt> and specify that location as the "Path to license file"<br />
<br />
Next you'll want to configure autobuild to use your build-cmd.sh.<br />
autobuild edit package<br />
# Name of package> hello<br />
# Package description> The GNU Hello program produces a familiar, friendly greeting. Yes, this is another implementation of the classic program that prints “Hello, world!” when you run it.<br />
# Copyright string (as appropriate for your package)> Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/><br />
# Type of license (as appropriate for your package)> gpl3<br />
# Path to license file relative to package root, if known> LICENSES/hello.txt<br />
# Version> 2.6<br />
hg add autobuild.xml<br />
autobuild edit build<br />
# Name of config> default<br />
# Platform of config> common<br />
# Command to execute> bash<br />
# Options for command> -c,../build-cmd.sh<br />
# Arguments for command><br />
autobuild edit platform name=linux build_directory=stage<br />
autobuild edit platform name=darwin build_directory=stage<br />
autobuild edit platform name=windows build_directory=stage<br />
autobuild edit build name=default platform=linux default=true<br />
autobuild edit build name=default platform=darwin default=true<br />
autobuild edit build name=default platform=windows default=true<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like this [[Autobuild/Quick_Start/Build Configured|autobuild print example]]<br />
<br />
Next you'll want to configure the manifest for packaging.<br />
<br />
autobuild manifest --platform common add "include/hello/*.h"<br />
autobuild manifest --platform common add "LICENSES/hello.txt"<br />
autobuild manifest --platform linux add "lib/*.a"<br />
autobuild manifest --platform darwin add "lib/*.a"<br />
autobuild manifest --platform windows add "lib/debug/*.pdb"<br />
autobuild manifest --platform windows add "lib/debug/*.lib"<br />
autobuild manifest --platform windows add "lib/release/*.pdb"<br />
autobuild manifest --platform windows add "lib/release/*.lib"<br />
autobuild manifest --platform linux add "bin/*"<br />
autobuild manifest --platform darwin add "bin/*"<br />
autobuild manifest --platform windows add "bin/*.exe"<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like this [[Autobuild/Quick_Start/Manifest Configured|autobuild manifest example]]<br />
<br />
Now things should be complete (for this simplified example), and you should be able to run <tt>autobuild build && autobuild package</tt> to get a package generated. Hooray!<br />
<br />
hg commit<br />
<br />
==What did we do==<br />
#We defined a build script that drives the native build of the package in a way that is compatible with our viewer builds and sandboxed from the rest of the system.<br />
# We configured autobuild to use that build script on all 3 platforms.<br />
#We packaged the result in a tarball consistent with [[Autobuild/Package_Layout]]<br />
<br />
==What haven't we done==<br />
<br />
# We haven't addressed how to handle dependencies. For example libcurl depends upon zlib and openssl already having their autobuild packages availible for use. If you're packaging a new library that has dependencies you should begin at the leaves of the dependency tree.<br />
#:[[Autobuild_How_To#Adding_dependencies]] covers this excellently.<br />
# We skipped features of autobuild that aren't useful for the way we're currently packaging third party library packages.<br />
## like multiple configurations (Debug/RelWithDebInfo/Release)<br />
## like options and arguments to the build command.<br />
## like distinct configure and build stages.<br />
# We haven't covered the specifics of how autobuild integrates with the windows Visual Studio build system.<br />
# We haven't covered specifically what the ABI requirements are for packages intended to be linked into the viewer.<br />
<br />
[[Category:Autobuild]] [[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Adding_Dependencies&diff=1134625Autobuild/Adding Dependencies2011-02-18T02:06:25Z<p>Brad Linden: </p>
<hr />
<div>Here are some examples for how to add and update installables for dependency packages. It's a work in progress.<br />
This picks up where [[Autobuild/Quick_Start]] left off.<br />
<br />
Example from this [http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-expat/rev/221208/index.html build]:<br />
autobuild installables add expat platform=windows url=http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-expat/rev/221208/arch/CYGWIN/installer/expat-2.0.1-windows-20110215.tar.bz2 hash=e72db1bda49b205ebdf4945d4ed2b8f8<br />
autobuild installables edit expat platform=linux url=http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-expat/rev/221208/arch/Linux/installer/expat-2.0.1-linux-20110215.tar.bz2 hash=750a6f119f828ba464029b7584acfc79<br />
autobuild installables edit expat platform=darwin url=http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-expat/rev/221208/arch/Darwin/installer/expat-2.0.1-darwin-20110215.tar.bz2 hash=a9fdcc2afc0a7f9711e28530f098e402</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Adding_Dependencies&diff=1134622Autobuild/Adding Dependencies2011-02-18T02:00:05Z<p>Brad Linden: Created page with "Example from this [http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-expat/rev/221208/index.html build]: autobuild installables add expat platform=windows url=h…"</p>
<hr />
<div>Example from this [http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-expat/rev/221208/index.html build]:<br />
autobuild installables add expat platform=windows url=http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-expat/rev/221208/arch/CYGWIN/installer/expat-2.0.1-windows-20110215.tar.bz2 hash=e72db1bda49b205ebdf4945d4ed2b8f8<br />
autobuild installables edit expat platform=linux url=http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-expat/rev/221208/arch/Linux/installer/expat-2.0.1-linux-20110215.tar.bz2 hash=750a6f119f828ba464029b7584acfc79<br />
autobuild installables edit expat platform=darwin url=http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-expat/rev/221208/arch/Darwin/installer/expat-2.0.1-darwin-20110215.tar.bz2 hash=a9fdcc2afc0a7f9711e28530f098e402</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Quick_Start&diff=1134619Autobuild/Quick Start2011-02-18T01:26:14Z<p>Brad Linden: /* What do we do */</p>
<hr />
<div>{{RightToc}}<br />
<br />
When creating a new autobuild package of a library, it can be unclear where to start. [[Autobuild How To]] can be a little intimidating. We're packaging a simple third party library just like all the rest of ours, so we don't need to use autobuild in it's full generality. We can skip some steps and share script fragments with other library packages.<br />
<br />
Autobuild is largely self documenting. You can access help via the commands <tt>autobuild --help</tt> or <tt>autobuild &lt;subcommand&gt; --help</tt>, for example <tt>autobuild edit --help</tt>. If the help text is unclear, please file a bug.<br />
<br />
Here's a crash course:<br />
<br />
==What will we be doing==<br />
<br />
Your packaging efforts will mostly consist of creating or modifying 2 files: autobuild.xml, and build-cmd.sh<br />
<br />
;autobuild.xml : Autobuild package definition metadata. For now, what you should focus on "This specifies the actual shell commands that autobuild should execute for each step." You should modify this file using the '<tt>autobuild edit</tt>' command. Editing it by hand will lead to problems.<br />
;build-cmd.sh : the shell script that we are going to specify as the build command in autobuild.xml we've encapsulated a lot of the complexity within this script for our third party libraries, so we can just clone it from an existing library and customize it for our package.<br />
<br />
==What do we do==<br />
Get autobuild:<br />
hg clone http://hg.secondlife.com/autobuild<br />
cd autobuild/bin<br />
export PATH="$PATH:$(pwd)"<br />
cd ../..<br />
<br />
Copy the skeleton from an existing package.<br />
hg init hello<br />
cd hello<br />
curl -OL http://hg.secondlife.com/3p-zlib/raw/tip/BuildParams<br />
curl -OL http://hg.secondlife.com/3p-zlib/raw/tip/build-cmd.sh<br />
chmod +x build-cmd.sh<br />
curl -OL http://hg.secondlife.com/3p-zlib/raw/tip/.hgignore<br />
hg add BuildParams build-cmd.sh .hgignore<br />
<br />
Now you'll need to edit build-cmd.sh and customize it for your package in our case, [http://www.gnu.org/software/hello/ GNU Hello]. Mostly this is just a search and replace (replace occurrences of curl and CURL with the name or your package). For example, the sed search & replace commands would be <tt>s/curl/hello/g</tt> and <tt>s/CURL/HELLO/g</tt> in this case. You'll likely also need to update the version number variables to match your package's version.<br />
<br />
Additionally you'll need to update the 3 sections under the case statement with any platform specific quirks for how to build your package natively. Darwin and Linux can be pretty standardized, but under windows there are a lot of different ways to build your package. Most of these have been worked through already for one package or another, so talk to a team [[Chopper]] member or scan [[Autobuild/Package Index]] if you need examples to imitate.<br />
<br />
<br />
In the end, you should come up with something like this [[Autobuild/Quick_Start/build-cmd.sh|example build-cmd.sh]].<br />
<br />
You'll need some information about your package from the upstream package distributor for filling in some of the prompts. For example you should copy the copyright string and license info verbatim from the upstream distributor. Additionally we should always write our build script to copy the text of the license into <tt>LICENSES/&lt;package name&gt;.txt</tt> and specify that location as the "Path to license file"<br />
<br />
Next you'll want to configure autobuild to use your build-cmd.sh.<br />
autobuild edit package<br />
# Name of package> hello<br />
# Package description> The GNU Hello program produces a familiar, friendly greeting. Yes, this is another implementation of the classic program that prints “Hello, world!” when you run it.<br />
# Copyright string (as appropriate for your package)> Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/><br />
# Type of license (as appropriate for your package)> gpl3<br />
# Path to license file relative to package root, if known> LICENSES/hello.txt<br />
# Version> 2.6<br />
hg add autobuild.xml<br />
autobuild edit build<br />
# Name of config> default<br />
# Platform of config> common<br />
# Command to execute> bash<br />
# Options for command> -c,../build-cmd.sh<br />
# Arguments for command><br />
autobuild edit platform name=linux build_directory=stage<br />
autobuild edit platform name=darwin build_directory=stage<br />
autobuild edit platform name=windows build_directory=stage<br />
autobuild edit build name=default platform=linux default=true<br />
autobuild edit build name=default platform=darwin default=true<br />
autobuild edit build name=default platform=windows default=true<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like this [[Autobuild/Quick_Start/Build Configured|autobuild print example]]<br />
<br />
Next you'll want to configure the manifest for packaging.<br />
<br />
autobuild manifest --platform common add "include/hello/*.h"<br />
autobuild manifest --platform common add "LICENSES/hello.txt"<br />
autobuild manifest --platform linux add "lib/*.a"<br />
autobuild manifest --platform darwin add "lib/*.a"<br />
autobuild manifest --platform windows add "lib/debug/*.pdb"<br />
autobuild manifest --platform windows add "lib/debug/*.lib"<br />
autobuild manifest --platform windows add "lib/release/*.pdb"<br />
autobuild manifest --platform windows add "lib/release/*.lib"<br />
autobuild manifest --platform linux add "bin/*"<br />
autobuild manifest --platform darwin add "bin/*"<br />
autobuild manifest --platform windows add "bin/*.exe"<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like this [[Autobuild/Quick_Start/Manifest Configured|autobuild manifest example]]<br />
<br />
Now things should be complete (for this simplified example), and you should be able to run <tt>autobuild build && autobuild package</tt> to get a package generated. Hooray!<br />
<br />
hg commit<br />
<br />
==What did we do==<br />
#We defined a build script that drives the native build of the package in a way that is compatible with our viewer builds and sandboxed from the rest of the system.<br />
# We configured autobuild to use that build script on all 3 platforms.<br />
#We packaged the result in a tarball consistent with [[Autobuild/Package_Layout]]<br />
<br />
==What haven't we done==<br />
<br />
# We haven't addressed how to handle dependencies. For example libcurl depends upon zlib and openssl already having their autobuild packages availible for use. If you're packaging a new library that has dependencies you should begin at the leaves of the dependency tree.<br />
# We skipped features of autobuild that aren't useful for the way we're currently packaging third party library packages.<br />
## like multiple configurations (Debug/RelWithDebInfo/Release)<br />
## like options and arguments to the build command.<br />
## like distinct configure and build stages.<br />
# We haven't covered the specifics of how autobuild integrates with the windows Visual Studio build system.<br />
# We haven't covered specifically what the ABI requirements are for packages intended to be linked into the viewer.<br />
<br />
[[Category:Autobuild]] [[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Quick_Start&diff=1134563Autobuild/Quick Start2011-02-17T17:47:23Z<p>Brad Linden: /* What do we do */</p>
<hr />
<div>{{RightToc}}<br />
<br />
When creating a new autobuild package of a library, it can be unclear where to start. [[Autobuild How To]] can be a little intimidating. We're packaging a simple third party library just like all the rest of ours, so we don't need to use autobuild in it's full generality. We can skip some steps and share script fragments with other library packages.<br />
<br />
Autobuild is largely self documenting. You can access help via the commands <tt>autobuild --help</tt> or <tt>autobuild &lt;subcommand&gt; --help</tt>, for example <tt>autobuild edit --help</tt>. If the help text is unclear, please file a bug.<br />
<br />
Here's a crash course:<br />
<br />
==What will we be doing==<br />
<br />
Your packaging efforts will mostly consist of creating or modifying 2 files: autobuild.xml, and build-cmd.sh<br />
<br />
;autobuild.xml : Autobuild package definition metadata. For now, what you should focus on "This specifies the actual shell commands that autobuild should execute for each step." You should modify this file using the '<tt>autobuild edit</tt>' command. Editing it by hand will lead to problems.<br />
;build-cmd.sh : the shell script that we are going to specify as the build command in autobuild.xml we've encapsulated a lot of the complexity within this script for our third party libraries, so we can just clone it from an existing library and customize it for our package.<br />
<br />
==What do we do==<br />
Get autobuild:<br />
hg clone http://hg.lindenlab.com/brad/autobuild-trunk<br />
cd autobuild-trunk/bin<br />
export PATH="$PATH:$(pwd)"<br />
cd ../..<br />
<br />
Copy the skeleton from an existing package.<br />
hg init hello<br />
cd hello<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/BuildParams<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/build.sh<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/build-cmd.sh<br />
chmod +x build.sh build-cmd.sh<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/.hgignore<br />
hg add BuildParams build.sh build-cmd.sh .hgignore<br />
<br />
Now you'll need to edit build-cmd.sh and customize it for your package in our case, [http://www.gnu.org/software/hello/ GNU Hello]. Mostly this is just a search and replace (replace occurrences of curl and CURL with the name or your package). For example, the sed search & replace commands would be <tt>s/curl/hello/g</tt> and <tt>s/CURL/HELLO/g</tt> in this case. You'll likely also need to update the version number variables to match your package's version.<br />
<br />
Additionally you'll need to update the 3 sections under the case statement with any platform specific quirks for how to build your package natively. Darwin and Linux can be pretty standardized, but under windows there are a lot of different ways to build your package. Most of these have been worked through already for one package or another, so talk to a team [[Chopper]] member or scan [[Autobuild/Package Index]] if you need examples to imitate.<br />
<br />
<br />
In the end, you should come up with something like this [[Autobuild/Quick_Start/build-cmd.sh|example build-cmd.sh]].<br />
<br />
You'll need some information about your package from the upstream package distributor for filling in some of the prompts. For example you should copy the copyright string and license info verbatim from the upstream distributor. Additionally we should always write our build script to copy the text of the license into <tt>LICENSES/&lt;package name&gt;.txt</tt> and specify that location as the "Path to license file"<br />
<br />
Next you'll want to configure autobuild to use your build-cmd.sh.<br />
autobuild edit package<br />
# Name of package> hello<br />
# Package description> The GNU Hello program produces a familiar, friendly greeting. Yes, this is another implementation of the classic program that prints “Hello, world!” when you run it.<br />
# Copyright string (as appropriate for your package)> Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/><br />
# Type of license (as appropriate for your package)> gpl3<br />
# Path to license file relative to package root, if known> LICENSES/hello.txt<br />
# Version> 2.6<br />
hg add autobuild.xml<br />
autobuild edit build<br />
# Name of config> default<br />
# Platform of config> common<br />
# Command to execute> ../build-cmd.sh<br />
# Options for command> <br />
# Arguments for command><br />
autobuild edit platform name=linux build_directory=stage<br />
autobuild edit platform name=darwin build_directory=stage<br />
autobuild edit platform name=windows build_directory=stage<br />
autobuild edit build name=default platform=linux default=true<br />
autobuild edit build name=default platform=darwin default=true<br />
autobuild edit build name=default platform=windows default=true<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like this [[Autobuild/Quick_Start/Build Configured|autobuild print example]]<br />
<br />
Next you'll want to configure the manifest for packaging.<br />
<br />
autobuild manifest --platform common add "include/hello/*.h"<br />
autobuild manifest --platform common add "LICENSES/hello.txt"<br />
autobuild manifest --platform linux add "lib/*.a"<br />
autobuild manifest --platform darwin add "lib/*.a"<br />
autobuild manifest --platform windows add "lib/debug/*.pdb"<br />
autobuild manifest --platform windows add "lib/debug/*.lib"<br />
autobuild manifest --platform windows add "lib/release/*.pdb"<br />
autobuild manifest --platform windows add "lib/release/*.lib"<br />
autobuild manifest --platform linux add "bin/*"<br />
autobuild manifest --platform darwin add "bin/*"<br />
autobuild manifest --platform windows add "bin/*.exe"<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like this [[Autobuild/Quick_Start/Manifest Configured|autobuild manifest example]]<br />
<br />
Now things should be complete (for this simplified example), and you should be able to run <tt>autobuild build && autobuild package</tt> to get a package generated. Hooray!<br />
<br />
hg commit<br />
<br />
==What did we do==<br />
#We defined a build script that drives the native build of the package in a way that is compatible with our viewer builds and sandboxed from the rest of the system.<br />
# We configured autobuild to use that build script on all 3 platforms.<br />
#We packaged the result in a tarball consistent with [[Autobuild/Package_Layout]]<br />
<br />
==What haven't we done==<br />
<br />
# We haven't addressed how to handle dependencies. For example libcurl depends upon zlib and openssl already having their autobuild packages availible for use. If you're packaging a new library that has dependencies you should begin at the leaves of the dependency tree.<br />
# We skipped features of autobuild that aren't useful for the way we're currently packaging third party library packages.<br />
## like multiple configurations (Debug/RelWithDebInfo/Release)<br />
## like options and arguments to the build command.<br />
## like distinct configure and build stages.<br />
# We haven't covered the specifics of how autobuild integrates with the windows Visual Studio build system.<br />
# We haven't covered specifically what the ABI requirements are for packages intended to be linked into the viewer.<br />
<br />
[[Category:Autobuild]] [[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Quick_Start&diff=1134560Autobuild/Quick Start2011-02-17T17:26:20Z<p>Brad Linden: /* What do we do */</p>
<hr />
<div>{{RightToc}}<br />
<br />
When creating a new autobuild package of a library, it can be unclear where to start. [[Autobuild How To]] can be a little intimidating. We're packaging a simple third party library just like all the rest of ours, so we don't need to use autobuild in it's full generality. We can skip some steps and share script fragments with other library packages.<br />
<br />
Autobuild is largely self documenting. You can access help via the commands <tt>autobuild --help</tt> or <tt>autobuild &lt;subcommand&gt; --help</tt>, for example <tt>autobuild edit --help</tt>. If the help text is unclear, please file a bug.<br />
<br />
Here's a crash course:<br />
<br />
==What will we be doing==<br />
<br />
Your packaging efforts will mostly consist of creating or modifying 2 files: autobuild.xml, and build-cmd.sh<br />
<br />
;autobuild.xml : Autobuild package definition metadata. For now, what you should focus on "This specifies the actual shell commands that autobuild should execute for each step." You should modify this file using the '<tt>autobuild edit</tt>' command. Editing it by hand will lead to problems.<br />
;build-cmd.sh : the shell script that we are going to specify as the build command in autobuild.xml we've encapsulated a lot of the complexity within this script for our third party libraries, so we can just clone it from an existing library and customize it for our package.<br />
<br />
==What do we do==<br />
Get autobuild:<br />
hg clone http://hg.lindenlab.com/brad/autobuild-trunk<br />
cd autobuild-trunk/bin<br />
export PATH="$PATH:$(pwd)"<br />
cd ../..<br />
<br />
Copy the skeleton from an existing package.<br />
hg init hello<br />
cd hello<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/BuildParams<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/build.sh<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/build-cmd.sh<br />
chmod +x build.sh build-cmd.sh<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/.hgignore<br />
hg add BuildParams build.sh build-cmd.sh .hgignore<br />
<br />
Now you'll need to edit build-cmd.sh and customize it for your package in our case, [http://www.gnu.org/software/hello/ GNU Hello]. Mostly this is just a search and replace (replace occurrences of curl and CURL with the name or your package). For example, the sed search & replace commands would be <tt>s/curl/hello/g</tt> and <tt>s/CURL/HELLO/g</tt> in this case. You'll likely also need to update the version number variables to match your package's version.<br />
<br />
Additionally you'll need to update the 3 sections under the case statement with any platform specific quirks for how to build your package natively. Darwin and Linux can be pretty standardized, but under windows there are a lot of different ways to build your package. Most of these have been worked through already for one package or another, so talk to a team [[Chopper]] member or scan [[Autobuild/Package Index]] if you need examples to imitate.<br />
<br />
<br />
In the end, you should come up with something like this [[Autobuild/Quick_Start/build-cmd.sh|example build-cmd.sh]].<br />
<br />
Next you'll want to configure autobuild to use your build-cmd.sh.<br />
autobuild edit package<br />
# Name of package> hello<br />
# Package description> The GNU Hello program produces a familiar, friendly greeting. Yes, this is another implementation of the classic program that prints “Hello, world!” when you run it.<br />
# Copyright string (as appropriate for your package)> Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/><br />
# Type of license (as appropriate for your package)> gpl3<br />
# Path to license file relative to package root, if known> LICENSES/hello.txt<br />
# Version> 2.6<br />
hg add autobuild.xml<br />
autobuild edit build<br />
# Name of config> default<br />
# Platform of config> common<br />
# Command to execute> ../build-cmd.sh<br />
# Options for command> <br />
# Arguments for command><br />
autobuild edit platform name=linux build_directory=stage<br />
autobuild edit platform name=darwin build_directory=stage<br />
autobuild edit platform name=windows build_directory=stage<br />
autobuild edit build name=default platform=linux default=true<br />
autobuild edit build name=default platform=darwin default=true<br />
autobuild edit build name=default platform=windows default=true<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like this [[Autobuild/Quick_Start/Build Configured|autobuild print example]]<br />
<br />
Next you'll want to configure the manifest for packaging.<br />
<br />
autobuild manifest --platform common add "include/hello/*.h"<br />
autobuild manifest --platform common add "LICENSES/hello.txt"<br />
autobuild manifest --platform linux add "lib/*.a"<br />
autobuild manifest --platform darwin add "lib/*.a"<br />
autobuild manifest --platform windows add "lib/debug/*.pdb"<br />
autobuild manifest --platform windows add "lib/debug/*.lib"<br />
autobuild manifest --platform windows add "lib/release/*.pdb"<br />
autobuild manifest --platform windows add "lib/release/*.lib"<br />
autobuild manifest --platform linux add "bin/*"<br />
autobuild manifest --platform darwin add "bin/*"<br />
autobuild manifest --platform windows add "bin/*.exe"<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like this [[Autobuild/Quick_Start/Manifest Configured|autobuild manifest example]]<br />
<br />
Now things should be complete (for this simplified example), and you should be able to run <tt>autobuild build && autobuild package</tt> to get a package generated. Hooray!<br />
<br />
hg commit<br />
<br />
==What did we do==<br />
#We defined a build script that drives the native build of the package in a way that is compatible with our viewer builds and sandboxed from the rest of the system.<br />
# We configured autobuild to use that build script on all 3 platforms.<br />
#We packaged the result in a tarball consistent with [[Autobuild/Package_Layout]]<br />
<br />
==What haven't we done==<br />
<br />
# We haven't addressed how to handle dependencies. For example libcurl depends upon zlib and openssl already having their autobuild packages availible for use. If you're packaging a new library that has dependencies you should begin at the leaves of the dependency tree.<br />
# We skipped features of autobuild that aren't useful for the way we're currently packaging third party library packages.<br />
## like multiple configurations (Debug/RelWithDebInfo/Release)<br />
## like options and arguments to the build command.<br />
## like distinct configure and build stages.<br />
# We haven't covered the specifics of how autobuild integrates with the windows Visual Studio build system.<br />
# We haven't covered specifically what the ABI requirements are for packages intended to be linked into the viewer.<br />
<br />
[[Category:Autobuild]] [[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Quick_Start&diff=1134559Autobuild/Quick Start2011-02-17T17:24:22Z<p>Brad Linden: /* What do we do */</p>
<hr />
<div>{{RightToc}}<br />
<br />
When creating a new autobuild package of a library, it can be unclear where to start. [[Autobuild How To]] can be a little intimidating. We're packaging a simple third party library just like all the rest of ours, so we don't need to use autobuild in it's full generality. We can skip some steps and share script fragments with other library packages.<br />
<br />
Autobuild is largely self documenting. You can access help via the commands <tt>autobuild --help</tt> or <tt>autobuild &lt;subcommand&gt; --help</tt>, for example <tt>autobuild edit --help</tt>. If the help text is unclear, please file a bug.<br />
<br />
Here's a crash course:<br />
<br />
==What will we be doing==<br />
<br />
Your packaging efforts will mostly consist of creating or modifying 2 files: autobuild.xml, and build-cmd.sh<br />
<br />
;autobuild.xml : Autobuild package definition metadata. For now, what you should focus on "This specifies the actual shell commands that autobuild should execute for each step." You should modify this file using the '<tt>autobuild edit</tt>' command. Editing it by hand will lead to problems.<br />
;build-cmd.sh : the shell script that we are going to specify as the build command in autobuild.xml we've encapsulated a lot of the complexity within this script for our third party libraries, so we can just clone it from an existing library and customize it for our package.<br />
<br />
==What do we do==<br />
Get autobuild:<br />
hg clone http://hg.lindenlab.com/brad/autobuild-trunk<br />
cd autobuild-trunk/bin<br />
export PATH="$PATH:$(pwd)"<br />
cd ../..<br />
<br />
Copy the skeleton from an existing package.<br />
hg init hello<br />
cd hello<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/BuildParams<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/build.sh<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/build-cmd.sh<br />
chmod +x build.sh build-cmd.sh<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/.hgignore<br />
hg add BuildParams build.sh build-cmd.sh .hgignore<br />
<br />
Now you'll need to edit build-cmd.sh and customize it for your package in our case, [http://www.gnu.org/software/hello/ GNU Hello]. Mostly this is just a search and replace (replace occurrences of curl and CURL with the name or your package). For example, the sed search & replace commands would be <tt>s/curl/hello/g</tt> and <tt>s/CURL/HELLO/g</tt> in this case. You'll likely also need to update the version number variables to match your package's version.<br />
<br />
Additionally you'll need to update the 3 sections under the case statement with any platform specific quirks for how to build your package natively. Darwin and Linux can be pretty standardized, but under windows there are a lot of different ways to build your package. Most of these have been worked through already for one package or another, so talk to a team [[Chopper]] member or scan [[Autobuild/Package Index]] if you need examples to imitate.<br />
<br />
<br />
In the end, you should come up with something like [[Autobuild/Quick_Start/build-cmd.sh|this]].<br />
<br />
Next you'll want to configure autobuild to use your build-cmd.sh.<br />
autobuild edit package<br />
# Name of package> hello<br />
# Package description> The GNU Hello program produces a familiar, friendly greeting. Yes, this is another implementation of the classic program that prints “Hello, world!” when you run it.<br />
# Copyright string (as appropriate for your package)> Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/><br />
# Type of license (as appropriate for your package)> gpl3<br />
# Path to license file relative to package root, if known> LICENSES/hello.txt<br />
# Version> 2.6<br />
hg add autobuild.xml<br />
autobuild edit build<br />
# Name of config> default<br />
# Platform of config> common<br />
# Command to execute> ../build-cmd.sh<br />
# Options for command> <br />
# Arguments for command><br />
autobuild edit platform name=linux build_directory=stage<br />
autobuild edit platform name=darwin build_directory=stage<br />
autobuild edit platform name=windows build_directory=stage<br />
autobuild edit build name=default platform=linux default=true<br />
autobuild edit build name=default platform=darwin default=true<br />
autobuild edit build name=default platform=windows default=true<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like [[Autobuild/Quick_Start/Build Configured|this]]<br />
<br />
Next you'll want to configure the manifest for packaging.<br />
<br />
autobuild manifest --platform common add "include/hello/*.h"<br />
autobuild manifest --platform common add "LICENSES/hello.txt"<br />
autobuild manifest --platform linux add "lib/*.a"<br />
autobuild manifest --platform darwin add "lib/*.a"<br />
autobuild manifest --platform windows add "lib/debug/*.pdb"<br />
autobuild manifest --platform windows add "lib/debug/*.lib"<br />
autobuild manifest --platform windows add "lib/release/*.pdb"<br />
autobuild manifest --platform windows add "lib/release/*.lib"<br />
autobuild manifest --platform linux add "bin/*"<br />
autobuild manifest --platform darwin add "bin/*"<br />
autobuild manifest --platform windows add "bin/*.exe"<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like [[Autobuild/Quick_Start/Manifest Configured|this]]<br />
<br />
Now things should be complete (for this simplified example), and you should be able to run <tt>autobuild build && autobuild package</tt> to get a package generated. Hooray!<br />
<br />
hg commit<br />
<br />
==What did we do==<br />
#We defined a build script that drives the native build of the package in a way that is compatible with our viewer builds and sandboxed from the rest of the system.<br />
# We configured autobuild to use that build script on all 3 platforms.<br />
#We packaged the result in a tarball consistent with [[Autobuild/Package_Layout]]<br />
<br />
==What haven't we done==<br />
<br />
# We haven't addressed how to handle dependencies. For example libcurl depends upon zlib and openssl already having their autobuild packages availible for use. If you're packaging a new library that has dependencies you should begin at the leaves of the dependency tree.<br />
# We skipped features of autobuild that aren't useful for the way we're currently packaging third party library packages.<br />
## like multiple configurations (Debug/RelWithDebInfo/Release)<br />
## like options and arguments to the build command.<br />
## like distinct configure and build stages.<br />
# We haven't covered the specifics of how autobuild integrates with the windows Visual Studio build system.<br />
# We haven't covered specifically what the ABI requirements are for packages intended to be linked into the viewer.<br />
<br />
[[Category:Autobuild]] [[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Quick_Start&diff=1134558Autobuild/Quick Start2011-02-17T17:22:41Z<p>Brad Linden: /* What do we do */</p>
<hr />
<div>{{RightToc}}<br />
<br />
When creating a new autobuild package of a library, it can be unclear where to start. [[Autobuild How To]] can be a little intimidating. We're packaging a simple third party library just like all the rest of ours, so we don't need to use autobuild in it's full generality. We can skip some steps and share script fragments with other library packages.<br />
<br />
Autobuild is largely self documenting. You can access help via the commands <tt>autobuild --help</tt> or <tt>autobuild &lt;subcommand&gt; --help</tt>, for example <tt>autobuild edit --help</tt>. If the help text is unclear, please file a bug.<br />
<br />
Here's a crash course:<br />
<br />
==What will we be doing==<br />
<br />
Your packaging efforts will mostly consist of creating or modifying 2 files: autobuild.xml, and build-cmd.sh<br />
<br />
;autobuild.xml : Autobuild package definition metadata. For now, what you should focus on "This specifies the actual shell commands that autobuild should execute for each step." You should modify this file using the '<tt>autobuild edit</tt>' command. Editing it by hand will lead to problems.<br />
;build-cmd.sh : the shell script that we are going to specify as the build command in autobuild.xml we've encapsulated a lot of the complexity within this script for our third party libraries, so we can just clone it from an existing library and customize it for our package.<br />
<br />
==What do we do==<br />
Get autobuild:<br />
hg clone http://hg.lindenlab.com/brad/autobuild-trunk<br />
cd autobuild-trunk/bin<br />
export PATH="$PATH:$(pwd)"<br />
cd ../..<br />
<br />
Copy the skeleton from an existing package.<br />
hg init hello<br />
cd hello<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/BuildParams<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/build.sh<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/build-cmd.sh<br />
chmod +x build.sh build-cmd.sh<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/.hgignore<br />
hg add BuildParams build.sh build-cmd.sh .hgignore<br />
<br />
Now you'll need to edit build-cmd.sh and customize it for your package in our case, [http://www.gnu.org/software/hello/ GNU Hello]. Mostly this is just a search and replace (replace occurrences of curl and CURL with the name or your package). For example, the sed search & replace commands would be <tt>s/curl/hello/g</tt> and <tt>s/CURL/HELLO/g</tt> in this case.<br />
<br />
Additionally you'll need to update the 3 sections under the case statement with any platform specific quirks for how to build your package natively. Darwin and Linux can be pretty standardized, but under windows there are a lot of different ways to build your package. Most of these have been worked through already for one package or another, so talk to a team [[Chopper]] member or scan [[Autobuild/Package Index]] if you need examples to imitate.<br />
<br />
<br />
In the end, you should come up with something like [[Autobuild/Quick_Start/build-cmd.sh|this]].<br />
<br />
Next you'll want to configure autobuild to use your build-cmd.sh.<br />
autobuild edit package<br />
# Name of package> hello<br />
# Package description> The GNU Hello program produces a familiar, friendly greeting. Yes, this is another implementation of the classic program that prints “Hello, world!” when you run it.<br />
# Copyright string (as appropriate for your package)> Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/><br />
# Type of license (as appropriate for your package)> gpl3<br />
# Path to license file relative to package root, if known> LICENSES/hello.txt<br />
# Version> 2.6<br />
hg add autobuild.xml<br />
autobuild edit build<br />
# Name of config> default<br />
# Platform of config> common<br />
# Command to execute> ../build-cmd.sh<br />
# Options for command> <br />
# Arguments for command><br />
autobuild edit platform name=linux build_directory=stage<br />
autobuild edit platform name=darwin build_directory=stage<br />
autobuild edit platform name=windows build_directory=stage<br />
autobuild edit build name=default platform=linux default=true<br />
autobuild edit build name=default platform=darwin default=true<br />
autobuild edit build name=default platform=windows default=true<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like [[Autobuild/Quick_Start/Build Configured|this]]<br />
<br />
Next you'll want to configure the manifest for packaging.<br />
<br />
autobuild manifest --platform common add "include/hello/*.h"<br />
autobuild manifest --platform common add "LICENSES/hello.txt"<br />
autobuild manifest --platform linux add "lib/*.a"<br />
autobuild manifest --platform darwin add "lib/*.a"<br />
autobuild manifest --platform windows add "lib/debug/*.pdb"<br />
autobuild manifest --platform windows add "lib/debug/*.lib"<br />
autobuild manifest --platform windows add "lib/release/*.pdb"<br />
autobuild manifest --platform windows add "lib/release/*.lib"<br />
autobuild manifest --platform linux add "bin/*"<br />
autobuild manifest --platform darwin add "bin/*"<br />
autobuild manifest --platform windows add "bin/*.exe"<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like [[Autobuild/Quick_Start/Manifest Configured|this]]<br />
<br />
Now things should be complete (for this simplified example), and you should be able to run <tt>autobuild build && autobuild package</tt> to get a package generated. Hooray!<br />
<br />
hg commit<br />
<br />
==What did we do==<br />
#We defined a build script that drives the native build of the package in a way that is compatible with our viewer builds and sandboxed from the rest of the system.<br />
# We configured autobuild to use that build script on all 3 platforms.<br />
#We packaged the result in a tarball consistent with [[Autobuild/Package_Layout]]<br />
<br />
==What haven't we done==<br />
<br />
# We haven't addressed how to handle dependencies. For example libcurl depends upon zlib and openssl already having their autobuild packages availible for use. If you're packaging a new library that has dependencies you should begin at the leaves of the dependency tree.<br />
# We skipped features of autobuild that aren't useful for the way we're currently packaging third party library packages.<br />
## like multiple configurations (Debug/RelWithDebInfo/Release)<br />
## like options and arguments to the build command.<br />
## like distinct configure and build stages.<br />
# We haven't covered the specifics of how autobuild integrates with the windows Visual Studio build system.<br />
# We haven't covered specifically what the ABI requirements are for packages intended to be linked into the viewer.<br />
<br />
[[Category:Autobuild]] [[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Quick_Start&diff=1134556Autobuild/Quick Start2011-02-17T17:21:08Z<p>Brad Linden: /* What do we do */ updated search and replace info with better details</p>
<hr />
<div>{{RightToc}}<br />
<br />
When creating a new autobuild package of a library, it can be unclear where to start. [[Autobuild How To]] can be a little intimidating. We're packaging a simple third party library just like all the rest of ours, so we don't need to use autobuild in it's full generality. We can skip some steps and share script fragments with other library packages.<br />
<br />
Autobuild is largely self documenting. You can access help via the commands <tt>autobuild --help</tt> or <tt>autobuild &lt;subcommand&gt; --help</tt>, for example <tt>autobuild edit --help</tt>. If the help text is unclear, please file a bug.<br />
<br />
Here's a crash course:<br />
<br />
==What will we be doing==<br />
<br />
Your packaging efforts will mostly consist of creating or modifying 2 files: autobuild.xml, and build-cmd.sh<br />
<br />
;autobuild.xml : Autobuild package definition metadata. For now, what you should focus on "This specifies the actual shell commands that autobuild should execute for each step." You should modify this file using the '<tt>autobuild edit</tt>' command. Editing it by hand will lead to problems.<br />
;build-cmd.sh : the shell script that we are going to specify as the build command in autobuild.xml we've encapsulated a lot of the complexity within this script for our third party libraries, so we can just clone it from an existing library and customize it for our package.<br />
<br />
==What do we do==<br />
Get autobuild:<br />
hg clone http://hg.lindenlab.com/brad/autobuild-trunk<br />
cd autobuild-trunk/bin<br />
export PATH="$PATH:$(pwd)"<br />
cd ../..<br />
<br />
Copy the skeleton from an existing package.<br />
hg init hello<br />
cd hello<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/BuildParams<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/build.sh<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/build-cmd.sh<br />
chmod +x build.sh build-cmd.sh<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/.hgignore<br />
hg add BuildParams build.sh build-cmd.sh .hgignore<br />
<br />
Now you'll need to edit build-cmd.sh and customize it for your package in our case, [http://www.gnu.org/software/hello/ GNU Hello]. Mostly this is just a search and replace (replace occurrences of curl and CURL with the name or your package).<br />
<br />
Additionally you'll need to update the 3 sections under the case statement with any platform specific quirks for how to build your package natively. Darwin and Linux can be pretty standardized, but under windows there are a lot of different ways to build your package. Most of these have been worked through already for one package or another, so talk to a team [[Chopper]] member or scan [[Autobuild/Package Index]] if you need examples to imitate.<br />
<br />
<br />
In the end, you should come up with something like [[Autobuild/Quick_Start/build-cmd.sh|this]].<br />
<br />
Next you'll want to configure autobuild to use your build-cmd.sh.<br />
autobuild edit package<br />
# Name of package> hello<br />
# Package description> The GNU Hello program produces a familiar, friendly greeting. Yes, this is another implementation of the classic program that prints “Hello, world!” when you run it.<br />
# Copyright string (as appropriate for your package)> Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/><br />
# Type of license (as appropriate for your package)> gpl3<br />
# Path to license file relative to package root, if known> LICENSES/hello.txt<br />
# Version> 2.6<br />
hg add autobuild.xml<br />
autobuild edit build<br />
# Name of config> default<br />
# Platform of config> common<br />
# Command to execute> ../build-cmd.sh<br />
# Options for command> <br />
# Arguments for command><br />
autobuild edit platform name=linux build_directory=stage<br />
autobuild edit platform name=darwin build_directory=stage<br />
autobuild edit platform name=windows build_directory=stage<br />
autobuild edit build name=default platform=linux default=true<br />
autobuild edit build name=default platform=darwin default=true<br />
autobuild edit build name=default platform=windows default=true<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like [[Autobuild/Quick_Start/Build Configured|this]]<br />
<br />
Next you'll want to configure the manifest for packaging.<br />
<br />
autobuild manifest --platform common add "include/hello/*.h"<br />
autobuild manifest --platform common add "LICENSES/hello.txt"<br />
autobuild manifest --platform linux add "lib/*.a"<br />
autobuild manifest --platform darwin add "lib/*.a"<br />
autobuild manifest --platform windows add "lib/debug/*.pdb"<br />
autobuild manifest --platform windows add "lib/debug/*.lib"<br />
autobuild manifest --platform windows add "lib/release/*.pdb"<br />
autobuild manifest --platform windows add "lib/release/*.lib"<br />
autobuild manifest --platform linux add "bin/*"<br />
autobuild manifest --platform darwin add "bin/*"<br />
autobuild manifest --platform windows add "bin/*.exe"<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like [[Autobuild/Quick_Start/Manifest Configured|this]]<br />
<br />
Now things should be complete (for this simplified example), and you should be able to run <tt>autobuild build && autobuild package</tt> to get a package generated. Hooray!<br />
<br />
hg commit<br />
<br />
==What did we do==<br />
#We defined a build script that drives the native build of the package in a way that is compatible with our viewer builds and sandboxed from the rest of the system.<br />
# We configured autobuild to use that build script on all 3 platforms.<br />
#We packaged the result in a tarball consistent with [[Autobuild/Package_Layout]]<br />
<br />
==What haven't we done==<br />
<br />
# We haven't addressed how to handle dependencies. For example libcurl depends upon zlib and openssl already having their autobuild packages availible for use. If you're packaging a new library that has dependencies you should begin at the leaves of the dependency tree.<br />
# We skipped features of autobuild that aren't useful for the way we're currently packaging third party library packages.<br />
## like multiple configurations (Debug/RelWithDebInfo/Release)<br />
## like options and arguments to the build command.<br />
## like distinct configure and build stages.<br />
# We haven't covered the specifics of how autobuild integrates with the windows Visual Studio build system.<br />
# We haven't covered specifically what the ABI requirements are for packages intended to be linked into the viewer.<br />
<br />
[[Category:Autobuild]] [[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Quick_Start&diff=1134554Autobuild/Quick Start2011-02-17T17:17:44Z<p>Brad Linden: /* What will we be doing */</p>
<hr />
<div>{{RightToc}}<br />
<br />
When creating a new autobuild package of a library, it can be unclear where to start. [[Autobuild How To]] can be a little intimidating. We're packaging a simple third party library just like all the rest of ours, so we don't need to use autobuild in it's full generality. We can skip some steps and share script fragments with other library packages.<br />
<br />
Autobuild is largely self documenting. You can access help via the commands <tt>autobuild --help</tt> or <tt>autobuild &lt;subcommand&gt; --help</tt>, for example <tt>autobuild edit --help</tt>. If the help text is unclear, please file a bug.<br />
<br />
Here's a crash course:<br />
<br />
==What will we be doing==<br />
<br />
Your packaging efforts will mostly consist of creating or modifying 2 files: autobuild.xml, and build-cmd.sh<br />
<br />
;autobuild.xml : Autobuild package definition metadata. For now, what you should focus on "This specifies the actual shell commands that autobuild should execute for each step." You should modify this file using the '<tt>autobuild edit</tt>' command. Editing it by hand will lead to problems.<br />
;build-cmd.sh : the shell script that we are going to specify as the build command in autobuild.xml we've encapsulated a lot of the complexity within this script for our third party libraries, so we can just clone it from an existing library and customize it for our package.<br />
<br />
==What do we do==<br />
Get autobuild:<br />
hg clone http://hg.lindenlab.com/brad/autobuild-trunk<br />
cd autobuild-trunk/bin<br />
export PATH="$PATH:$(pwd)"<br />
cd ../..<br />
<br />
Copy the skeleton from an existing package.<br />
hg init hello<br />
cd hello<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/BuildParams<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/build.sh<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/build-cmd.sh<br />
chmod +x build.sh build-cmd.sh<br />
curl -OL http://hg.lindenlab.com/brad/curl-autobuild/raw/tip/.hgignore<br />
hg add BuildParams build.sh build-cmd.sh .hgignore<br />
<br />
Now you'll need to edit build-cmd.sh and customize it for your package in our case, [http://www.gnu.org/software/hello/ GNU Hello]. Mostly this is just a search and replace, although you'll probably need to uncomment the fetch_archive line and the variables it uses (CURL_URL and CURL_MD5).<br />
<br />
Additionally you'll need to update the 3 sections under the case statement with any platform specific quirks for how to build your package natively. Darwin and Linux can be pretty standardized, but under windows there are a lot of different ways to build your package. Most of these have been worked through already for one package or another, so talk to a team [[Chopper]] member or scan [[Autobuild/Package Index]] if you need examples to imitate.<br />
<br />
<br />
In the end, you should come up with something like [[Autobuild/Quick_Start/build-cmd.sh|this]].<br />
<br />
Next you'll want to configure autobuild to use your build-cmd.sh.<br />
autobuild edit package<br />
# Name of package> hello<br />
# Package description> The GNU Hello program produces a familiar, friendly greeting. Yes, this is another implementation of the classic program that prints “Hello, world!” when you run it.<br />
# Copyright string (as appropriate for your package)> Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/><br />
# Type of license (as appropriate for your package)> gpl3<br />
# Path to license file relative to package root, if known> LICENSES/hello.txt<br />
# Version> 2.6<br />
hg add autobuild.xml<br />
autobuild edit build<br />
# Name of config> default<br />
# Platform of config> common<br />
# Command to execute> ../build-cmd.sh<br />
# Options for command> <br />
# Arguments for command><br />
autobuild edit platform name=linux build_directory=stage<br />
autobuild edit platform name=darwin build_directory=stage<br />
autobuild edit platform name=windows build_directory=stage<br />
autobuild edit build name=default platform=linux default=true<br />
autobuild edit build name=default platform=darwin default=true<br />
autobuild edit build name=default platform=windows default=true<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like [[Autobuild/Quick_Start/Build Configured|this]]<br />
<br />
Next you'll want to configure the manifest for packaging.<br />
<br />
autobuild manifest --platform common add "include/hello/*.h"<br />
autobuild manifest --platform common add "LICENSES/hello.txt"<br />
autobuild manifest --platform linux add "lib/*.a"<br />
autobuild manifest --platform darwin add "lib/*.a"<br />
autobuild manifest --platform windows add "lib/debug/*.pdb"<br />
autobuild manifest --platform windows add "lib/debug/*.lib"<br />
autobuild manifest --platform windows add "lib/release/*.pdb"<br />
autobuild manifest --platform windows add "lib/release/*.lib"<br />
autobuild manifest --platform linux add "bin/*"<br />
autobuild manifest --platform darwin add "bin/*"<br />
autobuild manifest --platform windows add "bin/*.exe"<br />
<br />
Now if you run <tt>autobuild print</tt> its output should look like [[Autobuild/Quick_Start/Manifest Configured|this]]<br />
<br />
Now things should be complete (for this simplified example), and you should be able to run <tt>autobuild build && autobuild package</tt> to get a package generated. Hooray!<br />
<br />
hg commit<br />
<br />
==What did we do==<br />
#We defined a build script that drives the native build of the package in a way that is compatible with our viewer builds and sandboxed from the rest of the system.<br />
# We configured autobuild to use that build script on all 3 platforms.<br />
#We packaged the result in a tarball consistent with [[Autobuild/Package_Layout]]<br />
<br />
==What haven't we done==<br />
<br />
# We haven't addressed how to handle dependencies. For example libcurl depends upon zlib and openssl already having their autobuild packages availible for use. If you're packaging a new library that has dependencies you should begin at the leaves of the dependency tree.<br />
# We skipped features of autobuild that aren't useful for the way we're currently packaging third party library packages.<br />
## like multiple configurations (Debug/RelWithDebInfo/Release)<br />
## like options and arguments to the build command.<br />
## like distinct configure and build stages.<br />
# We haven't covered the specifics of how autobuild integrates with the windows Visual Studio build system.<br />
# We haven't covered specifically what the ABI requirements are for packages intended to be linked into the viewer.<br />
<br />
[[Category:Autobuild]] [[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/How_To&diff=1132437Autobuild/How To2011-01-24T18:39:11Z<p>Brad Linden: /* Build for your platform(s) */</p>
<hr />
<div>Autobuild is an in-house framework for maintaining and building libraries. ('''Warning''': Our tool is distinct from [http://josefsson.org/autobuild/ GNU Autobuild] but they are similar enough to cause confusion.) It acts as director providing a common interface to build and package libraries, but it is not a build system like make or cmake. You will still need platform specific make, cmake, or project files to actually configure and build your library. Autobuild will, however, allow you invoke these commands and package the product with a common interface. Linden Lab Autobuild is designed as a replacement for the old [https://svn.lindenlab.com/svn/lindenlib/trunk lindelib] policies, doing the right thing so you don't have to.<br />
<br />
== Getting Autobuild ==<br />
Auotobuild is available as Mercurial repository which you may check out from http://bitbucket.org/lindenlab/autobuild. You can either run it directly from the checkout or install it as a normal python package using 'setup.py install'.<br />
<br />
== Using autobuild to build a library ==<br />
In this section we discuss how to configure autobuild to build a source package. We will assume that you have a source distribution with a build system like make or [http://www.cmake.org/ cmake] up and working.<br />
<br />
=== Before you start ===<br />
<br />
==== Build for your platform(s) ====<br />
Autobuild is not a build system like [http://www.gnu.org/software/make/ make] or [http://www.cmake.org/ cmake]. It is not intended to solve the nitty gritty problem of building code on particular platforms; it is designed to provide a common interface for builds and packaging on top of platform specific tools. You will need a single build (and possibly configure) command that actually complies the library or application you wish to manage with autobuild for every platform you support. For example, typical linux packages use make files and may be built by simply calling the <nowiki>make</nowiki> command. On windows you may call ''devenv.com'' passing a project file as an argument. In subsequent sections you will learn how to configure autobuild so that it can run your platform configuration and build commands.<br />
<br />
==== Understand autobuild ====<br />
Before you start it will be helpful if you familiarize yourself with the autobuild [[Autobuild/Class Model | class model]]. This page describes the structure of an autobuild configuration file explaining the function of the various elements it contains. The commands that follow in this document will follow the structure of the class model, so they may be easier to understand if you refer to it while going through this page.<br />
<br />
=== Basic build configuration ===<br />
<br />
The following steps will help you configure autobuild to run your package's configure and build commands by invoking nothing more than <br />
<br />
autobuild build<br />
<br />
To start you need to create an autobuild.xml configuration file. Change directories to the root of your package (or wherever you would like the configuration file to live) and invoke<br />
<br />
autobuild edit package<br />
<br />
This will start an interactive session in which you may fill in the general package details. Minimally you should provide a name and a version. If you intend to package your build into an archive, you will also want to specify a license and license file. We will ignore the other fields for now. As an alternative to the interactive session, you may add or change package fields all from the command line by passing ''field=value'' arguments on the command line. For all edit commands, the interactive mode will be used when no attribute arguments are passed and the non-interactive mode otherwise. For example to create our configuration file non-interactively you can invoke<br />
<br />
autobuild edit package name=test license=MIT license_file=LICENSES/test.txt version=1.0<br />
<br />
to create the '''test''' package version 1.0 using an MIT license. Now that we have defined some of the basic attributes for the package we need to configure the platforms on which we intend for the library to be built. At this level we can really only configure the build directory because we may define multiple build configurations (see below). The build directory is the directory in which autobuild will run the build and configure commands and is presumed to be where any build product will be generated. You can, for example, configure the MacOS X platform with<br />
<br />
autobuild edit platform name=darwin build_directory=build<br />
<br />
Note that for relative paths, the root is always the location of the autobuild configuration file. Now you need to add a build configuration which includes the build and configure commands which autobuild will invoke to make the package. Assuming you are dealing with a UNIX style package, you typically just call ''configure'' and ''make'' from the root directory to make the package. You can define the '''Release''' configuration to do just that using<br />
<br />
autobuild edit configure platform=darwin name=Release command=../configure<br />
autobuild edit build platform=darwin name=Release command=make options='--directory=..' default=True<br />
<br />
Note that these commands are run in the build directory so you need to set the path or add an option as appropriate to work select the root directory. The configure and build commands may take three attributes: '''command''', '''arguments''', and '''options'''. These are concatenated to produce the actual command invoked in the shell. The build configuration also supports the '''default''' option which flags a build configuration to be build by default if no configuration is specified when the autobuild ''build'' command is invoked. You may repeat these steps for other build configurations like '''Debug''' with different ''make'' and ''configure'' options to, for example, build a debug version of the library. You now have enough autobuild configuration to build a simple package for the Darwin platform. Simply run <br />
<br />
autobuild build<br />
<br />
to configure and make the package. To support other platform you need only repeat the package, config, and build configuration steps for the platform. <br />
<br />
In some cases you may find that your different platforms share a common command, arguments, or options. For example, a library configured by [http://www.cmake.org/ cmake] may use the same configuration command on all platforms because it is a cross-platform tool. In that case you can define the special platform '''common''' to define the commonalities. Attributes from build configurations in the '''common''' platform are inherited by those for the working platform. If a command is defined for a platform for a build configuration like '''Release''' for both a working platform like '''darwin''' that platform will inherit from '''common'''. This means that if the ''arguments'' or ''command'' is not specified in the working platform build configuration for either the '''build''' or '''configure''' command then value from the '''common''' will be used. Conversely, if the ''arguments'' or ''command'' attribute is defined in the working platform, it will supersede what is specified in '''common'''. However, the ''options'' for the commands from '''common''' will be concatenated with those specified in the working platform configuration with the common options preceding the working. Specifying a '''common''' platform can allow you to specify commands once per build configuration enabling a single point of truth for cross platform tools.<br />
<br />
=== Adding dependencies ===<br />
<br />
If your package depends on other archives, you can instuct autobuild to download and install those archives. This feature is useful for binary archives bundled as compressed tar files dowloadable from a url (typically generated by autobuild). First you will need to provide information in the autobuild configuration to identify and locate any package dependencies. You can add a package description of the installable archive using the ''installables'' command like the following<br />
<br />
autobuild installables add GL license=GPL license_file=LICENSES/GL.txt platform=darwin <br> url=http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-darwin-20101004.tar.bz2 hash=0b7c1d43dc2b39301fef6c05948fb826<br />
<br />
This creates a new entry in the installables dictionary that includes the information needed to download and verify the '''GL''' package for the '''darwin''' platform. You can add downloads for other platforms using the installables edit command<br />
<br />
autobuild installables edit GL platform=windows <br> url=http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-20101001a.tar.bz2 hash=a94538d064cd0a235b2a95389e7e8ee8<br />
<br />
Once an package has been added to the installables configuration for the platform you are working on, you can download it using the autobuild ''install'' command<br />
<br />
autobuild install GL<br />
<br />
The package contents will be downloaded and extracted into the '''packages''' directory inside the build directory configured for the working platform. Autobuild will conveniently track which packages are installed and what files were extracted only installing or updating files as needed. A package may be uninstalled with<br />
<br />
autobuild uninstall GL<br />
<br />
if it is no longer needed. If you update a package by changing its configuration in the installables configuration, autobuild will automatically clean up the older version so typically you will not need to uninstall packages.<br />
<br />
== Using autobuild to construct an archive ==<br />
<br />
=== Constructing the manifest and packaging ===<br />
<br />
Autobuild has the ability to construct a compressed tar archives with the autobuild ''package'' command, but to do that you must tell autobuild what to include in the archive. Typically you will be packaging an archive of build product generated by the autobuild ''build'' command, but that is not a requirement. Minimally you will need an autobuild configuration with the '''name''', '''license''', '''license_file''', and '''version''' attributes set and a platform configuration for the platform for which you wish to build and archive. You may then use the autobuild ''manifest'' command to add files which should be included in the archive. For example<br />
<br />
autobuild manifest add include/*.h<br />
<br />
will add the pattern 'include/*.h' to the manifest for the platform you are currently running (use the ''-p'' option to select another platform). Autoubuild supports simple glob patterns, so this pattern instructs autobuild to add all .h header files in the include directory to the archive. The root directory for all paths is assumed to be the build directory configured for the platform. You are strongly encouraged to use only relative paths in your manifest. Additional files may be added by calling ''manifest add'' again as needed (note that the ''add'' instruction can accept more than one pattern argument). Note that license file will automatically be included in the archive even if it is not explicitly listed in the manifest. If a file is to be included in every archive regardless of platform, you may add it to the manifest of the '''common''' platform.<br />
<br />
Once you have added all the files required by the archive listed in the manifest, you can generate the archive using<br />
<br />
autobuild package<br />
<br />
This command will generate an archive in the directory where the autobuild configuration file resides. Unless set using the ''--archive-name'' option, the archive will be named using the convention <nowiki><name>-<version>-<platform>-<date>.tar.bz2</nowiki>, e.g. test-1.0-darwin-20101020.tar.bz2 for the package described in this tutorial.<br />
<br />
=== Laying out build product ===<br />
<br />
Autobuild places no constraints on the layout of build product bundled into an archive, but there are some recommended conventions. The following table shows the recommended directory under which to place files of different types.<br />
<br />
{|border="1" style="background:white"<br />
|File type<br />
|Directory<br />
<br />
|-<br />
|license<br />
||LICENSES<br />
|-<br />
|header<br />
||include<br />
|-<br />
|libraries<br />
||lib<br />
|-<br />
|executables<br />
||bin<br />
|-<br />
|scripts<br />
||scripts<br />
|}<br />
<br />
For more details, see [[Autobuild/Package_Layout]]. By following these conventions you will help package users easily configure their build systems to find your files. For types not listed here it is recommended that you install files following well known conventions.<br />
<br />
[[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Autobuild/Package_Layout&diff=1131229Autobuild/Package Layout2011-01-10T21:28:14Z<p>Brad Linden: </p>
<hr />
<div>=== tarball layout ===<br />
<br />
*bin<br />
*cmake<br />
*include<br />
**include/<packagename><br />
*lib<br />
**lib/debug<br />
**lib/relwithdebinfo<br />
**lib/release<br />
**lib/python25<br />
*LICENSES<br />
<br />
=== gotchas ===<br />
<br />
# some existing packages have their libraries located directly under lib, some have them under lib/{debug,relwithdebinfo,release}<br />
# python pacakges are not fully supported, as we have not determined how to cleanly organize python module directories for compatibility with multiple python versions<br />
# this is not compatible with the legacy package layout used in the indra codebase, they need to be converted to the legacy layout to be used with install.py for now. UPDATE: {{User|Brad_Linden}} has gotten [[Autobuild/Teamcity|TeamCity]] to do this for us by using a BuildParam value to configure this (build_legacy_package can be set to true).<br />
<br />
[[Category:Open Source Portal]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Viewer_Update_Service/Protocol/v1.0&diff=1120322Viewer Update Service/Protocol/v1.02010-12-03T21:58:07Z<p>Brad Linden: Created page with 'The Update Service Protocol is implemented in the API presented by the Viewer Update Service. ==Basics== This design is the result of research and a whiteboard discussion f...'</p>
<hr />
<div>The Update Service Protocol is implemented in the API presented by the [[Viewer Update Service]].<br />
<br />
==Basics==<br />
<br />
This design is the result of research and a whiteboard discussion followed by comparison with and extension by [http://code.google.com/p/omaha/wiki/ServerProtocol Google's Omaha update server protocol].<br />
<br />
We chose XML as a format (rather than, say, just responding with a redirect to a download url) due to its extensibility. Example potential future uses include more granular updates, updates with dependencies, and more sophisticated user options and viewer behavior regarding updates.<br />
<br />
Rather than there being one update server per grid, there will be a single production update server, and test update servers as needed entirely unassociated with any particular grid.<br />
<br />
==Design==<br />
<br />
Requests are made to: https://update.secondlife.com/update<br />
<br />
===Request===<br />
<br />
Perform an HTTP GET to a URL of this form:<br />
<br />
'''<tt>https://<hostname>/update/<protocol version>/<channel>/<your version>/<platform></tt>'''<br />
<br />
''Example''<br />
<br />
GET https://update.secondlife.com/update/v1.0/Second%20Life%20Release/2.1.6.203021/win<br />
<br />
The 'v1.0' string is the version of the update service protocol version being used. This will enable us to maintain compatibility with older viewers when we choose to make changes to this service.<br />
<br />
===Response===<br />
<br />
200 OK<br />
<br />
''Content example''<br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<llsd><br />
<map><br />
<key>url</key><string>http://download.cloud.secondlife.com/thisupdate</string> <br />
<key>hash</key><string>12345ACDDEF9381</string><br />
<key>version</key><string>2.1.0.207030</string><br />
<key>required</key><boolean>False</boolean><br />
<key>size</key><integer>23467421</integer><br />
<key>channel</key><string>Second Life Release</string><br />
<key>pony</key><string>myponyurl</string><br />
<key>more_info</key><string>http://wiki.secondlife.com/thisinfo</string> <br />
<key>error_url</key><string>http://wiki.secondlife.com/myerorpage</string><br />
</map><br />
</llsd><br />
</pre><br />
<br />
'''Response Fields'''<br />
<br />
If no update is available, the response message body is an empty llsd container.<br />
<br />
If there is an update, the response will be populated as follows:<br />
<br />
* url: the url of the update to download<br />
* hash: the md5sum of the download<br />
* version: the version of the update linked to by the download url<br />
* required: boolean indicating whether an update is required<br />
* size (optional): the size in bytes of the download<br />
* channel (optional): repeat back the channel for which the update was requested<br />
* pony (optional): a link to a picture of a pony. Your reward for performing an update<br />
* more_info (optional): a url containing information about the update<br />
* error_url (optional): a url containing information about any error that may have occurred<br />
<br />
''Note: size may be removed, as we are getting this information from HTTP headers instead at the moment.''<br />
<br />
===Errors===<br />
<br />
'''404'''<br />
<br />
If you request a url that is not part of the defined update service interface, you'll receive a 404.<br />
<br />
'''500'''<br />
<br />
If the service hits an exception of some sort, it will return a 500.<br />
<br />
===Testing URLs===<br />
<br />
The following URL paths are provided for testing:<br />
<br />
<pre><br />
https://<hostname>/noupdate/v1.0/...<br />
https://<hostname>/updaterequired/v1.0/...<br />
https://<hostname>/updateoptional/v1.0/...<br />
</pre><br />
<br />
Where '...' is replaced with a normal request predicate. Responses indicating no update, update required, or update optional are returned as described by the path.<br />
<br />
For each of these, special channels will return differently formed responses, e.g.:<br />
<br />
<pre><br />
https://<hostname>/updateoptional/v1.0/Bad%20Hash/...<br />
</pre><br />
<br />
Available channels:<br />
<pre><br />
Bad%20Hash<br />
No%20Hash<br />
No%20URL<br />
No%20Size<br />
</pre><br />
<br />
...where each channel returns a response with the characteristic described by the channel name. All other channels besides these will return generic data containing correct hashes and urls for the platform requested.<br />
<br />
==Discussion==<br />
<br />
===Why LLSD?===<br />
<br />
We compared LLSD as a format to use against atom and straight XML. <br />
* Atom would be able to handle our current use-case, but would not handle the projected future use-case of more granular or dependency-driven updates as naturally.<br />
* We have server and client infrastructure in place to suport LLSD. We don't have the same infrastructure to support atom or straight XML <br />
* On the other hand, atom is an industry standard, with many pre-built tools and pre-made solutions.<br />
* Atom feeds already enjoy some industry adoption for udpater services, aka "appcasts".<br />
<br />
The cost of integrating a new xml library into our set of supported technologies and the tight time budget for version 1.0 of our updater service make atom and straight xml less desirable choices than LLSD at this time.</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Viewer_Update_Service/Protocol&diff=1120312Viewer Update Service/Protocol2010-12-03T21:57:59Z<p>Brad Linden: Redirected page to Viewer Update Service/Protocol/v1.0</p>
<hr />
<div>#REDIRECT [[Viewer Update Service/Protocol/v1.0]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Viewer_Update_Service&diff=1120302Viewer Update Service2010-12-03T21:57:53Z<p>Brad Linden: Created page with 'The Viewer Update Service is a web service living at https://update.secondlife.com to enable the new (as of viewer 2.4) Background Updater in the viewer. It publishes inform...'</p>
<hr />
<div>The [[Viewer Update Service]] is a web service living at https://update.secondlife.com to enable the new (as of viewer 2.4) Background Updater in the viewer. It publishes information about what updates are available or required for various viewer releases. It's protocol is documented here: [[Viewer Update Service/Protocol]]</div>Brad Lindenhttps://wiki.secondlife.com/w/index.php?title=Source_downloads&diff=45356Source downloads2007-12-20T23:13:19Z<p>Brad Linden: added release of windlight13_fl5 (r75963)|FL-1.18.5.75762</p>
<hr />
<div>__NOEDITSECTION__<br />
<br />
<br />
Below is a list of all of the releases of the Second Life viewer source code, in reverse chronological order. Be sure to pay attention to the {{OSWebsite|licenses|alt=applicable licenses}}. For build instructions, see [[Get source and compile]]<br />
<br />
{{CompileNav}}<br />
__TOC__<br />
<br />
= Releases and Release Candidates =<br />
<div id="box"><br />
{| border="1" cellspacing="0"<br />
|-<br />
|<br />
'''Date'''<br />
&nbsp;<br />
|<br />
'''Branch'''<br />
(see [[#Branching process|Branching process]] below)<br />
|<br />
'''Source'''<br />
&nbsp;<br />
|<br />
'''Libs'''<br />
&nbsp;<br />
|<br />
'''Build&nbsp;Notes'''<br />
&nbsp;<br />
{{SourceDownloadRowRelease|2007-Dec-12|Branch_1-18-6-Viewer (r75660)|RC-1.18.6.1|}}<br />
{{SourceDownloadRowRelease|2007-Dec-06|Branch_1-18-6-Viewer (r75180)|RC-1.18.6.0|}}<br />
{{SourceDownloadRowRelease|2007-Nov-29|Branch_1-18-5-Viewer (r74731)|1.18.5.3|Win VS2005: Use llmozlib-vc80.lib from RC-1.18.6.0 (above) }}<br />
{{SourceDownloadRowRelease|2007-Nov-25|Branch_1-18-5-Viewer (r74368)|RC-1.18.5.2|}}<br />
{{SourceDownloadRowRelease|2007-Nov-19|Branch_1-18-5-Viewer (r74065)|RC-1.18.5.1|}}<br />
{{SourceDownloadRowRelease|2007-Nov-13|Branch_1-18-5-Viewer (r73690)|RC-1.18.5.0|}}<br />
{{SourceDownloadRowRelease|2007-Nov-06|Branch_1-18-4-Viewer (r73187)|1.18.4.3|}}<br />
{{SourceDownloadRowRelease|2007-Nov-02|Branch_1-18-4-Viewer (r72877)|RC-1.18.4.2|}}<br />
{{SourceDownloadRowRelease|2007-Oct-29|Branch_1-18-4-Viewer (r72678)|RC-1.18.4.1|}}<br />
{{SourceDownloadRowRelease|2007-Oct-19|Branch_1-18-4-Viewer (r72016)|RC-1.18.4.0|{{JIRA|VWR-2856}}}}<br />
{{SourceDownloadRowRelease|2007-Sep-20|Branch_1-18-3-Viewer (r70186)|RC-1.18.3.5|}}<br />
{{SourceDownloadRowRelease|2007-Sep-10|Branch_1-18-2-viewer (r70095)|1.18.2.1|}}<br />
{{SourceDownloadRowRelease|2007-Sep-14|Branch_1-18-3-Viewer (r69773)|RC-1.18.3.4|}}<br />
{{SourceDownloadRowRelease|2007-Sep-13|Branch_1-18-3-Viewer (r69694)|RC-1.18.3.3|}}<br />
{{SourceDownloadRowRelease|2007-Aug-29|Branch_1-18-3-Viewer (r68777)|RC-1.18.3.2|Lin: {{JIRA|VWR-2275}}}}<br />
{{SourceDownloadRowRelease|2007-Aug-10|Branch_1-18-2-viewer (r67694)|1.18.2.0|}}<br />
{{SourceDownloadRowRelease|2007-Aug-02|Branch_1-18-1 (r67242)|1.18.1.2|}}<br />
{{SourceDownloadRowRelease|2007-Jul-11|Branch_1-18-0 (r65098)|1.18.0.6|Mac: {{JIRA|VWR-1381}}<br />Lin: {{JIRA|VWR-1697}}}}<br />
{{SourceDownloadRowRelease|2007-Jul-05|release (r64766)|1.17.3.0|Lin: {{JIRA|VWR-1697}}}}<br />
{{SourceDownloadRowRelease|2007-Jun-26|release (r64332)|1.17.2.0|Lin: {{JIRA|VWR-1697}}}}<br />
{{SourceDownloadRowRelease|2007-Jun-25|release (r64261)|1.17.1.0|Mac: {{JIRA|VWR-1381}}<br />Lin: {{JIRA|VWR-1697}}}}<br />
{{SourceDownloadRowRelease|2007-Jun-13|Branch_1-17-0 (r63642)|1.17.0.12|}}<br />
{{SourceDownloadRowRelease|2007-May-23|Branch_1-16-0 (r62325)|1.16.0.5|}}<br />
{{SourceDownloadRowRelease|2007-May-14|Branch_1-15-1 (r61825)|1.15.1.3|}}<br />
{{SourceDownloadRowRelease|2007-Apr-25|Branch_1-15-0 (r60933)|1.15.0.2|}}<br />
{{SourceDownloadRowRelease|2007-Apr-03|Branch_1-14-0 (r59907)|1.14.0.1|Mac: {{JIRA|VWR-169}}}}<br />
{{SourceDownloadRowRelease|2007-Mar-27|Branch_1-14-0 (r59765)|1.14.0.0|Mac: {{JIRA|VWR-169}}}}<br />
{{SourceDownloadRowRelease|2007-Jan-31|Branch_1-13-3 (r57502)|1.13.3.2|}}<br />
{{SourceDownloadRowRelease|2007-Jan-26|Branch_1-13-2 (r57190)|1.13.2.15|}}<br />
{{SourceDownloadRowRelease|2007-Jan-19|Branch_1-13-2 (r56958), last synced with release at r56659 |1.13.2.12|}}<br />
|}<br />
</div><br />
<br />
= Betas and First Look =<br />
<br />
<div id="box"><br />
{| border="1" cellspacing="0"<br />
|-<br />
|<br />
'''Date'''<br />
&nbsp;<br />
|<br />
'''Branch'''<br />
(see [[#Branching process|Branching process]] below)<br />
|<br />
'''Source'''<br />
&nbsp;<br />
|<br />
'''Libs'''<br />
&nbsp;<br />
|<br />
'''Build&nbsp;Notes'''<br />
&nbsp;<br />
{{SourceDownloadRowRelease|2007-Dec-20|windlight13_fl5 (r75962)|FL-1.18.6.75762|}}<br />
{{SourceDownloadRowRelease|2007-Dec-07|windlight12_fl4 (r75206)|FL-1.18.5.75173|}}<br />
{{SourceDownloadRowRelease|2007-Dec-04|windlight12_fl3_take2 (r74965)|FL-1.18.5.74965|}}<br />
{{SourceDownloadRowRelease|2007-Nov-21|windlight12 (r74061)|FL-1.18.5.74061|}}<br />
{{SourceDownloadRowRelease|2007-Jul-05|release-candidate (beta, r64762)|beta-1.18.0.4|Lin: {{JIRA|VWR-1697}}}}<br />
{{SourceDownloadRowRelease|2007-Jun-26|release-candidate (beta, r64324)|beta-1.18.0.3|Lin: {{JIRA|VWR-1401}}<br />Lin: {{JIRA|VWR-1697}}}}<br />
{{SourceDownloadRowRelease|2007-Jun-15|release-candidate (beta, r63874)|1.18.0.0|Lin: {{JIRA|VWR-1697}}<br /><br />Win: {{JIRA|VWR-1267}}<br />Mac/Lin: similar bug<br />[https://lists.secondlife.com/pipermail/sldev/2007-June/002580.html workaround] for all platforms}}<br />
{{SourceDownloadRowRelease|2007-Jun-07|non-voice-1-17-0 (beta, r63491)|1.17.0.11|}}<br />
{{SourceDownloadRowRelease|2007-Jun-07|non-voice-1-17-0 (beta, r63243)|1-17-0-9|}}<br />
{{SourceDownloadRowRelease|2007-May-05|sculpties2 (beta, r61424)|sculpties-1.16.0.0|}}<br />
{{SourceDownloadRowRelease|2007-Apr-19|Branch_1-15-0 (beta, r60612)|beta-1.15.0.0|}}<br />
{{SourceDownloadRowRelease|2007-Apr-13|release-candidate (beta, r60460)|beta-1.14.1.2|}}<br />
{{SourceDownloadRowRelease|2007-Apr-03|release-candidate (beta, r59992)|beta-1.14.1.1|Mac: {{JIRA|VWR-399}}<br />
<br />
Windows VS2005: {{JIRA|VWR-426}}}}<br />
{{SourceDownloadRowRelease|2007-Mar-21|Branch_1-14-0 (r59558, First Look)|FL-1.13.3.59558|Mac: {{JIRA|VWR-169}}}}<br />
{{SourceDownloadRowRelease|2007-Mar-20|Branch_1-14-0 (r59492 - branched from release at r59315, First Look)|FL-1.13.3.59492|Mac: {{JIRA|VWR-169}}}}<br />
{{SourceDownloadRowRelease|2007-Mar-16|release (r59315, First Look)|FL-1.13.3.59315|Mac: {{JIRA|VWR-169}}}}<br />
{{SourceDownloadRowRelease|2007-Mar-09|release (r59036, First Look)|FL-1.13.3.59036|}}<br />
{{SourceDownloadRowRelease|2007-Mar-09|release-candidate (beta, r59027)|beta-1.13.4.7|}}<br />
{{SourceDownloadRowRelease|2007-Mar-07|release (r58877, First Look)|FL-1.13.3.58877|}}<br />
{{SourceDownloadRowRelease|2007-Feb-27|release-candidate (beta, r58550)|beta-1.13.4.3|}}<br />
{{SourceDownloadRowRelease|2007-Feb-24|Branch_1-14-0 (First Look, r58390)|FL-1.13.3.58390|}}<br />
{{SourceDownloadRowRelease|2007-Feb-20|Branch_1-14-0 (First Look, r58185)|FL-1.13.3.58185|}}<br />
{{SourceDownloadRowRelease|2007-Feb-14|Branch_1-14-0 (First Look, r58018)|FL-1.13.3.58018|}}<br />
{{SourceDownloadRowRelease|2007-Feb-09|Branch_1-14-0 (First Look, r57876)|FL-1.13.3.57876|}}<br />
{{SourceDownloadRowRelease|2007-Feb-08|Branch_1-14-0 (First Look, r57837)|FL-1.13.3.57837|}}<br />
{{SourceDownloadRowRelease|2007-Feb-05|Branch_1-14-0 (First Look, r57679)|FL-1.13.3.57679|}}<br />
{{SourceDownloadRowRelease|2007-Feb-02|Branch_1-14-0 (First Look, r57575)|FL-1.13.3.57575|}}<br />
|-<br />
|| || || ||<br />
* [http://secondlife.com/developers/opensource/downloads/2007/02/slviewer-darwin-libcares-FL-1.13.3.57575.tar.gz Mac OS X libcares libraries (will be included with libraries next release)]<br />
|<br />
{{SourceDownloadRowRelease|2007-Jan-31|Branch_1-14-0 (First Look, r57520)|FL-1.13.3.57520|}}<br />
|-<br />
|| || || ||<br />
* [http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-textures-FL-1.13.3.57520.tar.gz Texture files (will be included with source next release)]<br />
|<br />
{{SourceDownloadRowRelease|2007-Jan-26|Branch_1-14-0 (First Look)|FL-1.13.2.57209|}}<br />
|}<br />
</div><br />
<br />
<br />
= Dated snapshots =<br />
<br />
<div id="box"><br />
{| border="1" cellspacing="0"<br />
|-<br />
|<br />
'''Date'''<br />
&nbsp;<br />
|<br />
'''Branch'''<br />
(see [[#Branching process|Branching process]] below)<br />
|<br />
'''Source'''<br />
&nbsp;<br />
|<br />
'''Libs'''<br />
&nbsp;<br />
|<br />
'''Build&nbsp;Notes'''<br />
&nbsp;<br />
{{SourceArchiveRow|2007-Dec-06|release (int svn rev 75267)|20071206a|}}<br />
{{SourceArchiveRow|2007-Oct-18|release (int svn rev 72020)|20071018a|}}<br />
{{SourceArchiveRow|2007-Sep-20|release (int svn rev 70180)|20070920a|}}<br />
{{SourceArchiveRow|2007-Sep-14|release (int svn rev 69811)|20070914a|}}<br />
{{SourceArchiveRow|2007-Sep-06|release (int svn rev 68919)|20070906a|}}<br />
{{SourceArchiveRow|2007-May-02|release (int svn rev 61266, ext svn rev 10)|20070502a|}}<br />
{{SourceArchiveRow|2007-May-02|release-candidate (int svn rev 61297, ext svn rev 12)|20070502b|}}<br />
{{SourceArchiveRow|2007-May-02|maintenance (int svn rev 61313, ext svn rev 13)|20070502c|}}<br />
{{SourceArchiveRow|2007-May-02|Branch_1-15-0 (int svn rev 61268, ext svn rev 11)|20070502d|}}<br />
{{SourceArchiveRow|2007-Mar-21|release (r59510)|20070321a|Mac: {{JIRA|VWR-169}}}}<br />
{{SourceArchiveRow|2007-Mar-05|release (r58754)|20070305a|}}<br />
{{SourceArchiveRow|2007-Jan-31|Release (r57511)|20070131a|}}<br />
{{SourceArchiveRow|2007-Jan-26|Release (r57221)|20070126a|}}<br />
{{SourceArchiveRow|2007-Jan-17|Release (r56851)|20070117a|}}<br />
|- valign="top"<br />
|'''(1.13.2.11)'''<br />
==2007-Jan-17==<br />
|Branch_1-13-2 (r56833), last synced with release at r56659<br />
|''links deleted: wrong source was uploaded''<br />
|''links deleted: wrong source was uploaded''<br />
|<br />
|- valign="top"<br />
|'''(20070112a)'''<br />
==2007-Jan-12==<br />
|Release (r56702)<br />
|'''Viewer'''<br />
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-src-20070112a.zip Windows (CRLF)]<br />
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-src-20070112a.tar.gz Mac/Linux (LF)]<br />
'''Other'''<br />
*[http://secondlife.com/developers/opensource/downloads/2007/01/llmozlib-src-20070112a.tar.gz llMozLib (LF)]<br />
| <br />
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-win32-libs-20070112a.zip Windows]<br />
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-darwin-libs-20070112a.tar.gz Mac]<br />
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-linux-libs-20070112a.tar.gz Linux] <br />
|<br />
|- valign="top"<br />
|'''(20070108c)'''<br />
==2007-Jan-08==<br />
|open source prep branch (r56647), branched from release (r56551)<br />
|'''Viewer'''<br />
*[http://secondlife.com/developers/opensource/downloads/slviewer-src-20070108c.zip Windows (CRLF)]<br />
*[http://secondlife.com/developers/opensource/downloads/slviewer-src-20070108c.tar.gz Mac/Linux (LF)]<br />
|<br />
*[http://secondlife.com/developers/opensource/downloads/slviewer-win32-libs-20070108c.zip Windows]<br />
*[http://secondlife.com/developers/opensource/downloads/slviewer-darwin-libs-20070108c.tar.gz Mac]<br />
*[http://secondlife.com/developers/opensource/downloads/slviewer-linux-libs-20070108c.tar.gz Linux] <br />
|<br />
|}<br />
</div><br />
<br />
<br />
The "branch" column indicates what branch the source was pulled from in Linden Lab's internal source repository, as well as the version number. This is helpful in determining how and when to do merges. See [[source branches]] page for more information about this.<br />
<br />
<br />
Note that the dated releases (e.g. 20070117a) are sourced from the working trunk (the "release" branch), and the numbered releases (e.g. 1.13.2.xx) are to sync with the official viewer releases.<br />
<br />
[[Image:Branching model.png]]<br />
<br />
<br />
= Support library source =<br />
* [[LogitechLCD]]<br />
** Current Version of the windows only project required to generate the lib that the viewer uses [http://secondlife.com/developers/opensource/downloads/2007/11/logitech-lcd-lib-gen-1.18.5.0.zip logitech_lib_project / 2007-11-15]<br />
<br />
<br />
* [[llMozLib]]<br />
** Current version<br />
*** Windows (CRLF/Zip) [http://secondlife.com/developers/opensource/downloads/2007/11/llmozlib-src-20071121.zip llMozLib / 2007-11-21]<br />
*** Mac/Linux (LF/tar.gz) [http://secondlife.com/developers/opensource/downloads/2007/11/llmozlib-src-20071121.tar.gz llMozLib / 2007-11-21]<br />
** Older versions<br />
*** Windows (CRLF/Zip) [http://secondlife.com/developers/opensource/downloads/2007/11/llmozlib-src-20071101.zip llMozLib / 2007-11-01]<br />
*** Mac/Linux (LF/tar.gz) [http://secondlife.com/developers/opensource/downloads/2007/11/llmozlib-src-20071101.tar.gz llMozLib / 2007-11-01]<br />
*** Mac/Linux (LF/tar.gz) [http://secondlife.com/developers/opensource/downloads/2007/01/llmozlib-src-20070112a.tar.gz llMozLib / 2007-01-12]</div>Brad Linden