FetchContent example

[stigrj]

Copied the pi example from externalproject to fetchcontent.

This version does not treat the current project as an external, as is done in the externalproject, not sure if this is wanted or not.

[bast]

ExternalProject allows better variable scope separation, FWIW. FetchContent makes it easier to access targets. So I think this is a good move. I am a bit confused about naming of directories (fetchcontent is for me an implementational detail so why is this the name of the directory?) but I recommend we merge and then I can suggest changes iteratively from there with follow-up PRs.

[stigrj]

The externalproject and fetchcontent directories are two different cmake setups of the same example code. I guess the idea was to show how both cmake strategies work?

[bast]

Ah OK sorry, then it makes a lot of sense.

[bast]

Can we avoid the configuration of the source file and rather pass the information as command line argument to the binary?

This is not a merge blocker though. This is personal taste. Motivation is that *.in source files are often not correctly highlighted and people editing them may need to understand CMake.

[robertodr]

I second Radovan's suggestion about passing executable as argument.

[bast]

Also gives more flexibility to try out stuff without reconfiguring/rebuilding.

[stigrj]

So if I have a sample input file in

example/pi.inp

I would run as something like this?

$ ../build/bin/pi -x ../build/bin/pi.x -t ../src/template.yml pi.inp

I guess the template file should also be shipped along with the executables when building and installing? If so, where to?

[bast]

What is the difference between bin/pi and bin/pi.x?

I guess the template file should also be shipped along with the executables when building and installing? If so, where to?

Yes, I think so. Where to I am not sure yet. Either a subdirectory or perhaps "datadir" of https://www.gnu.org/prep/standards/html_node/Directory-Variables.html

[stigrj]

pi.x is the c++ executable that accepts a JSON input. pi is a python script that runs parselglossy on the user input and calls pi.x with the processed JSON.

If we anyway pass the executable and template as arguments it would be easier to drop the python script and just use the parselglossy CLI instead. Perhaps this was the intention?

[bast]

To me this suggestion sounds good. @robertodr do we see this correctly?

[robertodr]

So it will be:

parselglossy ...
pi.x input.json

right?

I like it, for this simple example. For more complicated programs (like MRChem), the front-end script would do more than just the parsing, but that's beyond the scope of this tutorial repo.

[stigrj]

@bast can you have a look at the fetchcontent/tests/runtest_config.py? I now run parselglossy as a subprocess in configure. The actual integration test is the C++ executable with parsed JSON input.

Any suggestion for fixing the template path in this file?

[stigrj]

It's might be better to run parselglossy in the individual test scripts for each integration test, before the call to runtest.run?

[bast]

I'll have a look and report back ...

[stigrj]

In the latest commit I moved the parselglossy parse up one level to the test scripts, but that required a manual copy of the input file to the binary test dir. Not sure which of the last two commits is preferred?

[bast]

Now looking at it ...

[bast]

Running the parselglossy step in the test script is more explicit but the question is whether the tests are supposed to mirror tests in production codes which will probably abstract the parselglossy step and hide it inside the launcher. So the question is how visible you want it to be.

So the question is for me:

• are the tests mirroring a real-life situation for end-users? in this case we should perhaps abstract it out.
• or are the tests documenting how to interface codes for developers? then explicit may be better than implicit.

The '../../../src/template.yml' could be solved with a symlink.

[stigrj]

If we parse in the test script we can loop over different grammars and perform the same test for getkw, dalton, etc syntaxes. Do we support any other grammars atm?

[stigrj]

Now passing template.yml around to share/ dirs