Answers: <p>In many cases compilers are used as-is, already packaged by 3rd parties. When changing the structure of the build systems changing compilers usually translates into switching to a different version, but which is also pre-packaged. If this is your use case the artifact repository offers a single advantage: availability. Even if the provider decides (for whatever reason) to discontinue the version - you still have your copy in the respository.</p>
  
  <p>But if the compilers receive any updates without version changes or if you do any sort of customisation - even if it's just building them without touching any code - you want to store those particular versions in the artifactory to be able to reliably obtain them at any time.</p>
  
  <p>Side note: how exactly you use the compilers can influence the performance of your builds, especially in very large projects with build times which can take hours. You'd have to analyze your builds' structure and/or usage patterns to figure out if it's worth pursuing optimisations and, if so, in which direction(s).</p>
  
  <p>Directly invoking compilers from NFS is convenient - very little configurations required on the build servers. But performance of massive builds can be very sensitive to the NFS performance, of both the NFS server itself and of the network connecting it to the build server(s). Some artifactories may have direct NFS support. You'd have to measure the impact of switching to such service, in some cases it may still be better to use a dedicated NFS server instead. Or maybe switching to VM images that contain the compilers locally installed.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-02-05T16:40:58.710Z
Answers: We will be using JFrog, which I am pretty sure has NFS support if I am not mistaken.
Answers: scott
Answers: CC BY-SA 3.0
Answers: 2018-02-03T19:54:53.830Z
Answers: 2018-02-03T19:54:53.830Z
Answers: Dan Cornilescu
Answers: <p>There are a few main reasons why you would use Artifactory (or any other binary repository manager) over a traditional file storage (in your case NFS). </p>
  
  <ol>
  <li>The ability to manage your artifact versions</li>
  <li>A central location to access artifacts across infrastructure (which you have accomplished with NFS)</li>
  <li>The ability to download/recreate previous versions of the artifacts (you could also use a git/svn repository for this, but it would be contain MUCH more irrelevant metadata about the binary artifacts than would be useful to a user)</li>
  <li>You want to control who/what has permissions to access the stored artifacts</li>
  </ol>
  
  <p>If none of these are applicable in your use-case, I would say that Artifactory would be overkill and the effort to create and maintain it would not out way the value you would receive from it. Although I have used it in the past, and it is a great tool for what it aims to accomplish :)</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-02-02T22:59:49.553Z
Answers: 2018-02-02T22:59:49.553Z
Answers: Preston Martin
Answers: <p>One solution that might fit your scenario are <a href="http://modules.sourceforge.net/" rel="nofollow noreferrer">environment modules</a>. Given that you only need the compilers on Linux, and have access via a network share (nfs/Samba). To load a toolchain into your terminal, just type</p>
  
  <pre><code>module load gcc
  </code></pre>
  
  <p>and let autocompletion fill in the version number. It is basically Python’s virtualenv for any Linux program/toolchain/SDK. I have used it extensively and can warmly recommend this tool.</p>
  
  <p>Each compiler would have their own folder which is subdivided by version which allows you to have direct access to all versions. Configuration is defined server-side with PATH and other environment variables. User-side,  a bash script has to be installed into users’ <code>.bashrc</code></p>
  
Answers: CC BY-SA 3.0
Answers: 2018-02-03T09:04:25.690Z
Answers: 2018-02-03T09:04:25.690Z
Answers: Moritz
Body: <p>We are setting up our source and build system in AWS.  we will have two persistent VMs hosting source and artifactory.  We have a bunch of compilers (a few Gigs) we want available via NFS, is this something that should be hosted in artifactory? </p>
  
  <p>I'm looking for the 'best practice' answer.  I can't find much info on the thought behind this so any links would be appreciated. </p>
  
Comments: CC BY-SA 3.0
Comments: 2018-02-02T16:54:48.710Z
Comments: What is the use case for the compilers? Will they be downloaded onto a VM when it is created? Are the compilers ever updated?
Comments: Preston Martin
Comments: CC BY-SA 3.0
Comments: 2018-02-02T18:07:44.980Z
Comments: Compilers? Javac?
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-02-02T20:43:59.850Z
Comments: We are NFS mounting them, not downloading them.  The compilers are rarely updated, but will be occasionally(every several months).  They are CCs for c/c++, altera, etc. (we do all server/embedded/firmware work).
Comments: scott
Tags: <amazon-web-services><builds><artifacts><artifactory>
Title: Should compilers be kept in artifactory?
UserDisplayName: scott
ThreadText: # Should compilers be kept in artifactory?
  
  (Asked by: username_0 on 2018-02-02)
  
  We are setting up our source and build system in AWS. we will have two persistent VMs hosting source and artifactory. We have a bunch of compilers (a few Gigs) we want available via NFS, is this something that should be hosted in artifactory?
  
  I'm looking for the 'best practice' answer. I can't find much info on the thought behind this so any links would be appreciated.
  
  **Tags:** amazon-web-services, builds, artifacts, artifactory
  
  > **Comments:**
  > **username_1**: What is the use case for the compilers? Will they be downloaded onto a VM when it is created? Are the compilers ever updated?  
  > **username_2**: Compilers? Javac?  
  > **username_0**: We are NFS mounting them, not downloading them.  The compilers are rarely updated, but will be occasionally(every several months).  They are CCs for c/c++, altera, etc. (we do all server/embedded/firmware work).  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_3 on 2018-02-03. Score: 2 | Accepted answer
  
  In many cases compilers are used as-is, already packaged by 3rd parties. When changing the structure of the build systems changing compilers usually translates into switching to a different version, but which is also pre-packaged. If this is your use case the artifact repository offers a single advantage: availability. Even if the provider decides (for whatever reason) to discontinue the version - you still have your copy in the respository.
  
  But if the compilers receive any updates without version changes or if you do any sort of customisation - even if it's just building them without touching any code - you want to store those particular versions in the artifactory to be able to reliably obtain them at any time.
  
  Side note: how exactly you use the compilers can influence the performance of your builds, especially in very large projects with build times which can take hours. You'd have to analyze your builds' structure and/or usage patterns to figure out if it's worth pursuing optimisations and, if so, in which direction(s).
  
  Directly invoking compilers from NFS is convenient - very little configurations required on the build servers. But performance of massive builds can be very sensitive to the NFS performance, of both the NFS server itself and of the network connecting it to the build server(s). Some artifactories may have direct NFS support. You'd have to measure the impact of switching to such service, in some cases it may still be better to use a dedicated NFS server instead. Or maybe switching to VM images that contain the compilers locally installed.
  
  > **Comments:**
  > **username_0**: We will be using JFrog, which I am pretty sure has NFS support if I am not mistaken.  
  
  ---
  
  ### Answer by username_1 on 2018-02-02. Score: 3
  
  There are a few main reasons why you would use Artifactory (or any other binary repository manager) over a traditional file storage (in your case NFS).
  
  1. The ability to manage your artifact versions
  2. A central location to access artifacts across infrastructure (which you have accomplished with NFS)
  3. The ability to download/recreate previous versions of the artifacts (you could also use a git/svn repository for this, but it would be contain MUCH more irrelevant metadata about the binary artifacts than would be useful to a user)
  4. You want to control who/what has permissions to access the stored artifacts
  
  If none of these are applicable in your use-case, I would say that Artifactory would be overkill and the effort to create and maintain it would not out way the value you would receive from it. Although I have used it in the past, and it is a great tool for what it aims to accomplish :)
  
  
  ---
  
  ### Answer by username_4 on 2018-02-03. Score: 1
  
  One solution that might fit your scenario are [environment modules](http://modules.sourceforge.net/). Given that you only need the compilers on Linux, and have access via a network share (nfs/Samba). To load a toolchain into your terminal, just type
  
  ```
  module load gcc
  
  ```
  
  and let autocompletion fill in the version number. It is basically Python’s virtualenv for any Linux program/toolchain/SDK. I have used it extensively and can warmly recommend this tool.
  
  Each compiler would have their own folder which is subdivided by version which allows you to have direct access to all versions. Configuration is defined server-side with PATH and other environment variables. User-side, a bash script has to be installed into users’ `.bashrc`
  
  
  ---
  
  