Re-compile and re-install

[entropy]

Hello,

I have built and installed Cantera from source on GNU/Linux Ubuntu Trusty 14.04.3 LTS x86_64 following the compilation instructions provided (http://cantera.github.io/docs/sphinx/html/compiling.html). All tests pass and I can use successfully Cantera. The only (I believe, minor) difference is that I checked out version 2.2 executing

git checkout 2.2

after having cloned the repository.

Now I would like to make some modifications to the source code, re-compile and re-install the modified version. My take would be to repeat

scons build
scons test
sudo scons install

trying to remember the options I selected the first time and pass them again. But I am not sure if it is the right way to proceed and I am afraid to screw-up my current installation.

Is there any pointer to the right procedure? I know this is probably a very basic question but unfortunately I could not find any answer and I have no previous experience.

Regards,

Emanuele

[Bryan W. Weber]

Dear Emanuele,

There are a couple of ways you can proceed here. First, though, to reassure you about the command line options - there should be a file saved in the root Cantera source code directory called cantera.conf. This file contains a copy of all the options you passed to the command line, plus any options that were already in that file. So, if you run a plain scons build with no options on the command line, it will simply read the cantera.conf file and apply any options it finds in there. No need to remember them! Now, to procedures for re-compiling:

1) You can use the python_prefix='USER' and prefix='~/.local' options. This installseverything into the ~/.local folder which is automatically on the PYTHONPATH. This directory will be searched before /usr/local, so it will not disrupt the "working" version you have in the /usr/local directory. However, switching back and forth between the ~/.local and the /usr/local versions is somewhat tedious.

2) This way is probably the simpler way if you want to test some changes repeatedly.You can run just the build and test commands (don't run the install command), and then run Python with this command

PYTHONPATH=build/pythonX pythonX

where X is the version of Python you want to use (2 or 3). Your current directory in Bash has to be the root Cantera directory (the same one where you run scons build). This sets the value of the PYTHONPATH environment variable immediately before running the Python executable. It adds the directory where the Python interface is stored before it gets copied to the install location to the PYTHONPATH so that Python knows to look in the build/pythonX directory to try and find packages.

Hope it helps,

Bryan

[entropy]

Hi Bryan,

On Friday, November 13, 2015 at 1:04:49 PM UTC, Bryan W. Weber wrote:

Dear Emanuele,

There are a couple of ways you can proceed here. First, though, to reassure you about the command line options - there should be a file saved in the root Cantera source code directory called cantera.conf. This file contains a copy of all the options you passed to the command line, plus any options that were already in that file. So, if you run a plain scons build with no options on the command line, it will simply read the cantera.conf file and apply any options it finds in there. No need to remember them! Now, to procedures for re-compiling:

Odd: my cantera.conf file is empty. Does this mean I have not passed any options when I built the package? I remember for sure to have specified at least  "-j4". I hope to have not accidentally corrupted my source tree.

1) You can use the python_prefix='USER' and prefix='~/.local' options. This installs everything into the ~/.local folder which is automatically on the PYTHONPATH. This directory will be searched before /usr/local, so it will not disrupt the "working" version you have in the /usr/local directory. However, switching back and forth between the ~/.local and the /usr/local versions is somewhat tedious.

2) This way is probably the simpler way if you want to test some changes repeatedly.You can run just the build and test commands (don't run the install command), and then run Python with this command

PYTHONPATH=build/pythonX pythonX

where X is the version of Python you want to use (2 or 3). Your current directory in Bash has to be the root Cantera directory (the same one where you run scons build). This sets the value of the PYTHONPATH environment variable immediately before running the Python executable. It adds the directory where the Python interface is stored before it gets copied to the install location to the PYTHONPATH so that Python knows to look in the build/pythonX directory to try and find packages.

Unfortunately, I don't use python. Right now, I am trying to modify the C++ interface and call it from Fortran (https://groups.google.com/forum/#!topic/cantera-users/vSxi4mauXto). However, I think I can grasp the underlying logic of your suggestions and, hopefully, I will be able to adapt it for my needs.

Still, the question on how to proceed in case I would like to finalise the changes I have made in a local directory remains open.

Hope it helps,

Bryan

You helped me very much, thank you!

Regards,

Emanuele

[Bryan W. Weber]

Hi Emanuele,

Ah, the option -j is not stored in that file. Other options, such as the install prefix or the version of Python interface to use, are stored in that file.

If you use the C++ interface, I think you can add the appropriate directories in the build/root directory to your compiler/linker line, especially if you don't use something complicated like SUNDIALS. That is, you can say

g++ ...... -Lbuild/lib libcantera.a -Iinclude source_file.cpp

but I have almost no experience with the C++/Fortran interfaces, so I'll defer to someone else with a recommendation of best practice. Alternatively, you could install to a temporary directory by setting the prefix option in cantera.conf and add that directory to your compiler/linker line.

Best,

Bryan

[Ray Speth]

The distinction between different options is that options that apply to SCons itself and do not affect the result of the build, like -j4, are not saved, while the options that configure Cantera are saved in cantera.conf.

To compile against the built source tree, Bryan's suggestion is basically correct, but you should specify '-lcantera' instead of the full file name 'libcantera.a'. If you aren't sure what additional libraries need to be linked, you can look at one of the generated SConstruct files that are included with the C++ examples in the installation directory.

Regards,

Ray

[Nick Curtis]

Hi Emanuelle,

RE: C++ changes etc.
What I did when working on updates to underlying C++ code was as follows:

1)  Keep a separate folder of the the base cantera git clone.  This will make it easier to merge changes back if you want, and also to test your changes (if they're more than cosmetic).  The cantera.conf in this directory should be configured to install to something like, ~/cantera_base

2)  Clone that directory (or just do another git clone) for your working directory.  Have this one install to (say) ~/cantera_working (via the prefix and/or other arguments in the scons file, check scons help for the full list).

3)  Source the correct cantera setup_cantera file in your .bashrc (or .profile etc.) according to which version you're working on. 

I don't know how compatible this is with different python installs (though I suspect it should work), but since you're mostly working on the underlying C++ code it should work like a charm.

I also extended this to use compiled debug versions of Cantera/Sundials for the occasions I needed to step allll the way into whatever code I was working on.

Now, as far as scons goes.  If all you're doing is modifying the base Cantera C++ code (i.e. you're not adding new / removing .cpp files), you can simply use scons build (with your stored settings in cantera.conf), and test/reinstall.

If you're adding new compiled files (i.e. .cpp), you will probably need to dive into the scons code to make sure they actually get compiled correctly, as I'm not sure if the cantera scons utilizes a Glob to find all cpp files in a directory or the like

Nick

On Friday, November 13, 2015 at 8:34:14 AM UTC-5, entropy wrote:

[entropy]

Bryan, Ray, Nick,

thanks for the pointers. Unfortunately, I have been tied up and I didn't have time to test any of the proposed suggestions. I will post again here to report news as soon as I'll have a chance to look into this.

Regards,

Emanuele