I'm planning a new build system for our project running on Centos 5.4. I intend to use SCons. I noticed the latest stable SCons version is 2.0.1 while Centos 5.4 comes with 1.2.
I'm new to SCons so I'd like to understand more about the features/stability ratio between the versions.
Would you recommend installing and using the latest version or sticking to what comes from my OS repository?
Since 1.2 the changes have been bug fixes and documentation improvements. There haven't been any new features.
The 2.x version of SCons drops support for Python versions older than 2.4, updating some of the internal code to use newer idioms but without affecting any user visible APIs. That's the reason for the major version number change. If CentOS comes with a recent version of python then this won't affect you either way.
There have been a lot of fixes for newer versions of the various Microsoft compiler versions, but this won't affect a CentOS install.
The bug fixes since SCons 1.2.0 also solve problems in the Fortran, TeX and LaTeX builders. If you make use of Fortran or LaTeX then it would probably be worth upgrading. Otherwise I think you would be hard pushed to spot any day-to-day difference between 1.2.0 and 2.0.1.
Related
When we ssh onto this Linux server, it says Welcome to Ubuntu 16.04.7 LTS (GNU/Linux 4.4.0-193-generic x86_64), so this is the type of server we are on.
When we run R to launch R in the server from terminal, and then version, we get:
What is the easiest way to upgrade from version 3.4.4 to version 3.5.3? We don't want to upgrade to v4 or to the latest version quite yet until we ensure no breaking issues with our codebase on R v4, however we would like to make this upgrade to 3.5.3 so we can run an R library that requires 3.5.3+.
How can we do this from the command line on the server here, and after switching from 3.4.4 to 3.5.3 do we then need to re-install all R libraries on the server as well? I'm worried if I start running stuff from the command line and I mess up that I'll break our current R app.
I would be surprised if there is a .deb available for this OS release/R release combination.
This page only offers R 4.1, but as far back as 16.04 LTS
This page offers older R versions, but only back to 18.04 LTS
It's also possible that one of the backports on the Debian packages page would work on your system (it reports that 3.5.3 is available for Debian "jessie", although I have no idea how that lines up with Ubuntu releases).
I guess it's possible that one of those .debs works for your system though ... ? If you do install from .deb, you may have to be careful not to clobber your current version (e.g. using the --instdir argument to dpkg).
Building from source:
download the source tarball for R 3.5.3
untar, ./configure, make, sudo make install (assuming you have all the necessary development tools, system libraries, etc.; you'll have to troubleshoot/install as you go along)
It might be worth ./configure --prefix=/path/to/testdir to put the new version in a completely separate location, just to make extra-sure you don't stomp on your current install. (This would also simplify the library-path stuff below.)
Packages do need to be re-installed when switching major versions (e.g. 3.4.x to 3.5.x); one way to do it is to copy the system library of packages to a new place (adjust library paths as necessary; see R installation and administration manual).
Then, you should be able to update.packages(checkBuilt=TRUE, ask=FALSE) to update everything.
The tricky spots are (1) getting the library paths right (this will depend a bit on how things are set up in your existing installation; (2) it's conceivable that some current versions of packages on CRAN will fail to re-install/re-build under R 3.5.3. devtools::install_version() would help, although you'd have to track down the correct version manually. I recall someone posting about a package that would install an archived version by date, which could save a lot of poking around ...
How can I delete the older version of an application before installing the newer released version?
In other words, is there a way to automatically remove "MSIXDemoInstaller_1.0.0.0_Test" file before installing "MSIXDemoInstaller_1.0.1.0_Test" file?
You don't have to do anything special for this, the OS will handle it automatically. Just increase the version when building your new version. When you install it on a machine with the old version the OS will automatically apply it as an upgrade.
I am running R 3.6.1 on a Mac Mini running Sierra and a MacBook Pro running El Capitan. I normally get all the R packages that I need from CRAN or github and use them without issues, but I am trying to install and use an R package (NicheMapR) that requires a fortran compiler and this is giving me issues. Even after installing gfortran, the R package still does not work (the fortran code seems to be compiled but the package installation fails). The package developer suggested that installing R via homebrew might solve the problem. On the contrary, my hunch is that it would lead to a world of pain, to quote Walter from the Big Lebowski. My questions are:
What is the advantage of a homebrew version of R for MacOSX over the "regular" version installed from CRAN?
Can the two versions coexist?
Is the homebrew version going to affect the regular one?
Finally: is homebrew going to help or will it simply open a whole
new can of worms?
Many thanks in advance.
Yes, installing from homebrew is a recipe for pain. It's specifically recommended against by the official CRAN binary maintainer see his remarks from March 2016 on r-sig-mac.
Regarding your questions, this can be summarized as:
What is the advantage of a homebrew version of R for MacOSX over the "regular" version installed from CRAN?
Positives: Select your own BLAS and easily work with geospatial tools.
Downsides: Always needing to compile each R package.
Can the two versions coexist?
Yes. The homebrew version installs into a different directory. But, watch out for library collision (see next question). However, you will have to deal with symbolic linking regarding what version of R is accessible from the console and you will also need to look into using RSwitch to switch between R versions.
Is the homebrew version going to affect the regular one?
Yes, if the library paths overlap. There will be problems regarding package installation and loading. Make sure to setup different library paths. To do so, please look at the .libPaths() documentation.
Finally: is homebrew going to help or will it simply open a whole new can of worms?
Yes and no. Unless you know what you're doing, opt for the CRAN version of R and its assorted goodies.
We are currently running version 4.0.3 and can't go to the latest as support for our database has been dropped (SQL Server 2012). I would like to get the latest version 4 release (4.2.0) - can anyone tell me if this is possible and if so, where can I find it?
Apparently the source code for all previous versions is in GitHub. Now the question becomes "Is there anywhere I can find the Windows executable version of Flyway 4.2.0?"...
You will probably have to build the executable from source using one of the releases on their Github. 4.2.0 is available here
The various binaries, as well as the source, for 4.2.0 can be downloaded from Maven Central.
Here is the 4.2.0 Windows zip.
When I install.package() in R on a Windows machine, the package downloads from CRAN and installs. When I do the same on a Linux box, the package usually has to compile (at least, I assume that's what going with all those g++ lines that scroll past).
Why is the package installation method different on Windows?
Other questions and their answers make it clear that using different methods and repositories for Linux particularly, enables users to get more/different packages (particularly using the cran2deb repository). My question is more theoretical in nature: why is the default choice in Windows to download precompiled (binary?) packages whereas the default in Linux seems to be to compile packages from source?
Or to put it another way (based on Dirk's assertion in the second link above), why doesn't CRAN offer binary packages for Unix-type operating systems?
In general, Windows binaries will work on all versions of Windows.
Ditto for the key / current versions of MacOS: the provided binaries work.
Linux, sadly, is more complicated because the different distros lay things out differently. Something I build on Ubuntu or Debian (or, more specifically, a particular release version thereof) may not even work on other releases of the same distro, let alone other distro. In some cases you can get binaries. At some point I (co-)owned a build service for all of CRAN, but it died/broke. All doable with effort, but ... some effort.
So from source it is. That use to be the standard anyway which "Unix" was a catch-all phrase covering SunOS/Solaris, AIX, *BSD, SGI and on and on. Often even with different processors. So source.
There have been attempts to provide 'universal binaries': flatpack and snap are two more recent examples. And then there is of course Docker.