Message-ID: <27838399.299108.1368968297505.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_299107_1272622417.1368968297505" ------=_Part_299107_1272622417.1368968297505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page will serve as brainstorm for all the features that mav= en should provide in order to support builds in other languages than Java.<= /p>
Inicial discussion is for C and C++ builds.
Currently there are two plugins: NAR Plu= gin and native C-build Plugin
Explanation of the NAR plugin
The nar plugin builds a jar with a file that acts as a pointer to other fil= es in the repo:
AOL stand for Architecture, OS, Linker, but may not be enough, the value= s needed to identify uniquely a system are
Distribution may imply the os in all cases but one, under windows you ma= y have cygwin or other environment.
This would be hard to manage, so the proposed system id is:
This new type would be mapped in the repository expanded (at least in th=
e local repository) because the compiler doesn't understand compressed file=
s. It may be stored in the remote repo as a tgz an uncompressed when downlo=
aded, deleting the compressed version and keeping the name.
NOTE take a look at the naming convention used by linux
This will work for almost any organization, where there isn't a lot of s= imilar environments. eg. for a version of a distribution there's no people = with different compiler versions. This won't work for a internet wide binar= y repository, so the suggestion is to limit it to source artifacts.
At some point in the future we may try to standardize the user defined p= ortion.
BTW this problem also happens in java, where you can have different comp= iler versions (1.3, 1.4, 1.5,...)
For building all the current plugins use the cpp ant tasks------=_Part_299107_1272622417.1368968297505--