[pbachant]

I was able to build for OpenFOAM-3.0.x a while back, but now it's failing with commit 23bcea0299 of dev. I have tried the master and port_of-dev branches of the swak repo to no avail. Are swak and dev incompatible?

Here's the error message I'm getting:

In file included from /home/pete/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/typeInfo.H:57:0,
                 from /home/pete/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/token.H:46,
                 from /home/pete/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/UListIO.C:28,
                 from /home/pete/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/UList.C:225,
                 from /home/pete/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/UList.H:462,
                 from /home/pete/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/List.H:43,
                 from /home/pete/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/labelList.H:48,
                 from /home/pete/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/UPstream.H:42,
                 from /home/pete/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/Pstream.H:42,
                 from lnInclude/DebugOStream.H:55,
                 from lnInclude/swak.H:333,
                 from makeSwakDataEntry.C:34:
/home/pete/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/DataEntry.H:192:59: error: expected initializer before ‘<’ token
     defineNamedTemplateTypeNameAndDebug(DataEntryTypes::SS<Type>, 0);

Full log: https://gist.github.com/petebachant/...53168f8de43224

[wyldckat]

Quick answer: OpenFOAM-dev is the bleeding-edge of the OpenFOAM development line.

If I remember correctly, about a week ago, "DataEntry" was renamed to "Function1something" in OpenFOAM-dev, so that it could contemplate other generic data types that are 1 argument input data types and give way for future 2 or more input data types.
Since it was done around a week ago, it's only natural that the swak4Foam development line isn't updated yet

May I suggest that since (if I remember correctly) you already have some experience with Travis-CI and if you want to contribute to swak4Foam, an automated reporting mechanism would come in handy for swak4Foam and other similar projects for keeping on-par to when they break building whenever OpenFOAM-dev gets such a similar upgrade!

[pbachant]

I figured it was something like that. I have a little experience with Travis CI. I believe it requires the project be on GitHub. Would it be advisable to submit a PR to the mirror at https://github.com/Unofficial-Extend...swak4Foam-dev?

[wyldckat]

Originally Posted by pbachant

Would it be advisable to submit a PR to the mirror at https://github.com/Unofficial-Extend...swak4Foam-dev?

Quick answer: I believe that I can then convert the pull request into a Mercurial bundle package, at the very least manually and then submit it through swak4Foam's bug tracker.

[pbachant]

Oh, I meant to setup Travis. I guess there would be no harm in having a .travis.yml file back in the Mercurial repo on Sourceforge (?). If the mirror on GitHub is pushed to just as often, it can be cloned from there.

[wyldckat]

Oh, now I get it!
Well... the mirror system currently in place is a bit wonky, because the Mercurial-to-Git extension that is currently being used isn't 100% full-proof, since Mercurial sometimes lets some neat features to occur, which are not translated directly to Git by the extension.
And the mirror is using tiny VMs on OpenShift, which have to be manually woken up once in a while... therefore, if it's not awake, it won't mirror .

However, SourceForge.net does support webhooks: https://forge-allura.apache.org/p/allura/wiki/Webhooks/

[rupole1185]

I am interested into the same thing as well ... Did you manage to install swak4foam on the dev version? What did you change and have you commit it to some repo?

[pbachant]

So... I think setting up Travis for swak would be a lot easier if there were nightly deb pack builds of OF-dev. I am working on getting Travis to build OF-dev right now. Is there a recipe for building a deb pack?

[pbachant]

I started playing a bit with Travis for checking swak can build with OF-dev, but for some reason, it can't find the Pstream.H file. Any idea why this is happening?

Full log: https://travis-ci.org/petebachant/op...ilds/110993952

[wyldckat]

Quick answers:

Originally Posted by rupole1185

I am interested into the same thing as well ... Did you manage to install swak4foam on the dev version? What did you change and have you commit it to some repo?

OpenFOAM-dev is undergoing a ton of changes in the past few weeks. Syncing swk4Foam with the latest changes will likely only be done when OpenFOAM-dev stabilizes for at least 1 or 2 weeks, otherwise it might build today and break tomorrow

Originally Posted by pbachant

So... I think setting up Travis for swak would be a lot easier if there were nightly deb pack builds of OF-dev. I am working on getting Travis to build OF-dev right now. Is there a recipe for building a deb pack?

Deb pack specs are not yet publicly available. There's a bug report where the team told us that the Deb specs weren't in a state that could be mad public.
It's easier if you do a local build, tarball it, upload to your own fork on a tag-release as a binary package and then download and unpack it from the Travis bot.

Originally Posted by pbachant

I started playing a bit with Travis for checking swak can build with OF-dev, but for some reason, it can't find the Pstream.H file. Any idea why this is happening?

Full log: https://travis-ci.org/petebachant/op...ilds/110993952

Several issues, but according to the logs on builds #5 and #6, you did source the shell script for loading the OpenFOAM environment, but you didn't run "Allwmake -j" afterwards. Therefore, there is no OpenFOAM built for swak4Foam to link to.

OK, Travis-CI has Ubuntu 12.04 as production default and Ubuntu 14.04 as beta. I'll try to build OpenFOAM-dev on a VM (or maybe in Docker) with 14.04 and then I'll upload the build snapshot, so you can use it as well.

[rupole1185]

Originally Posted by wyldckat

Quick answers:

OpenFOAM-dev is undergoing a ton of changes in the past few weeks. Syncing swk4Foam with the latest changes will likely only be done when OpenFOAM-dev stabilizes for at least 1 or 2 weeks, otherwise it might build today and break tomorrow


Deb pack specs are not yet publicly available. There's a bug report where the team told us that the Deb specs weren't in a state that could be mad public.
It's easier if you do a local build, tarball it, upload to your own fork on a tag-release as a binary package and then download and unpack it from the Travis bot.


Several issues, but according to the logs on builds #5 and #6, you did source the shell script for loading the OpenFOAM environment, but you didn't run "Allwmake -j" afterwards. Therefore, there is no OpenFOAM built for swak4Foam to link to.

OK, Travis-CI has Ubuntu 12.04 as production default and Ubuntu 14.04 as beta. I'll try to build OpenFOAM-dev on a VM (or maybe in Docker) with 14.04 and then I'll upload the build snapshot, so you can use it as well.

Ok. Please keep me up to date please.

All the best

[pbachant]

I was able to at least setup Travis to try building OpenFOAM-dev, but it just takes too long. Do you know off-hand which parts I could build for a barebones check of swak compatibility, or a smart way to split OpenFOAM's Allwmake script into smaller jobs?

[wyldckat]

Originally Posted by pbachant

I was able to at least setup Travis to try building OpenFOAM-dev, but it just takes too long. Do you know off-hand which parts I could build for a barebones check of swak compatibility, or a smart way to split OpenFOAM's Allwmake script into smaller jobs?

This is not an easy feat. swak4Foam is hooked up to a lot of features in OpenFOAM. The simplest would be to only build the libraries in "src", by running something like this:

(cd wmake/src && make)
src/Allwmake -j 2 > log.make.src 2>&1

But it will still take a ton of time to build.


But worry not, I've got the first (complete) build up, although it's only 64-bit + Double Precision + 32-bit labels (integers) (and no ParaView ):

• For the OpenFOAM-dev bin packages: https://github.com/wyldckat/OpenFOAM...0160227-181109
• For the ThirdParty-dev bin packages: https://github.com/wyldckat/ThirdPar...0160227-181109

To use them, after you do this:

git clone https://github.com/OpenFOAM/OpenFOAM-dev.git
git clone https://github.com/OpenFOAM/ThirdParty-dev.git

you then do something like this (please get the actual links from the ):

wget https://....../OpenFOAM-dev.linux64GccDPInt32Opt_2016-02-27.tbz
wget https://....../ThirdParty-dev.linux64GccDPInt32Opt_2016-02-27.tbz

tar -xf OpenFOAM-dev.linux64GccDPInt32Opt_2016-02-27.tbz
tar -xf ThirdParty-dev.linux64GccDPInt32Opt_2016-02-27.tbz

Note: If the "-xf" option doesn't work, try "-xjf", since it's compressed with bzip2.

Then use the source command:

source $HOME/OpenFOAM/OpenFOAM-dev/etc/bashrc

Et voilà, instant OpenFOAM-dev installation ready to go.


But keep in mind that this is built with Ubuntu 14.04.4... which I certainly hope this will work with Travis-CI's "Ubuntu 14.04.3 LTS" that the log states in your builds that it's using.


By the way, the steps I used in Docker are here: https://github.com/wyldckat/wyldckat...cker-on-Ubuntu


If we can get prove this concept, then we can later streamline the build system. By the way, the build with 64-bit labels will be up possibly only tomorrow morning... with any luck.

[pbachant]

I am getting the same error now actually, and I have even tested with `icoFoam -help` that OpenFOAM is installed correctly. It still can't find "Pstream.H":

https://travis-ci.org/petebachant/op...12319371#L3016

[wyldckat]

Sorry about that .
There is one very important command missing for rebuilding all of the "lnInclude" folders, which are not packaged into the binary packages:

wmakeLnIncludeAll

So I would suggest adding after the source command doing the following steps:

cd OpenFOAM-dev
wmakeLnIncludeAll

Then, proceed as you have so far.

Hopefully I didn't miss anything else.

[pbachant]

Alright! The requirements can build now. Is there a plan for automatically building OpenFOAM-dev/ThirdParty-dev so those binaries can stay up to date?

[wyldckat]

Hi Pete,

Originally Posted by pbachant

Alright! The requirements can build now.

Nice! Congrats! Great work on this!

Originally Posted by pbachant

Is there a plan for automatically building OpenFOAM-dev/ThirdParty-dev so those binaries can stay up to date?

Well, the next step is to first get swak4Foam getting built properly with the latest OpenFOAM-dev commits.

The latest issue for swak4Foam to build is related to the revamp recently made by Henry Weller to the "tmp" class, which has now been made a lot more consistent on object accesses by reference.
The downside is that it's going to be a bit annoying to provide yet another compatibility layer to swak4Foam The most likely scenario is to use a template wrapper class that reproduces the OpenFOAM-dev format into the older OpenFOAM versions/forks. I still believe that something akin to Python Six will have to be created to make it easier to compensate for all of these changes throughout all versions and forks... given that more projects are coming forward that have compatibility issues between versions/forks

Anyway, after the issues are resolved, there are a few details that need to be taken care of:

1. Will the build system be possible using an online machine, which can deliver timely builds?
   • One possibility is to piggyback on Launchpad's facilities, but that still requires creating a proper Debian spec folder.
   • Another is relying on Travis-CI, but it would probably take a few days for it to manage to finish each build... which isn't entirely bad, but a bit annoying if the continuous-integration loop is meant to have a diagnosis on all covered projects within 12-24h or so...
   • The other possibility is to get the OpenFOAM Foundation some funding to get this system going...
2. Still need to check if it's possible to use Github's API for automatic uploads of builds.
3. Should a single tag be used for these builds? And/or should new tags be created and then gradually kill off outdated tags?
4. Last but not least, then we will have to hook up the uploaded builds into automatically triggering the swak4Foam-dev builds onto Travis-CI as well.

Best regards,
Bruno

[pbachant]

If swak is to be compatible with every version/fork of OpenFOAM, including old versions, that will be quite the build matrix. Building against older versions with deb packs should be pretty straightforward though.

[pbachant]

A little more progress... I setup the build matrix to compile against OpenFOAM 3.0 as well, which passes: https://travis-ci.org/petebachant/op...ilds/112353517

[wyldckat]

Originally Posted by pbachant

If swak is to be compatible with every version/fork of OpenFOAM, including old versions, that will be quite the build matrix. Building against older versions with deb packs should be pretty straightforward though.

We're limited on how far we can get with OpenFOAM versions, given that OpenFOAM deb packages are only supported for a few specific Ubuntu versions and the open-source Travis CI service seems to be for a single Ubuntu version. But I guess that having a proof of concept for OpenFOAM 3.0 is a good start.

Originally Posted by pbachant

A little more progress... I setup the build matrix to compile against OpenFOAM 3.0 as well, which passes: https://travis-ci.org/petebachant/op...ilds/112353517

This is great! There is a way to have a quick and dirty way of creating a Debian folder for making builds of OpenFOAM on Launchpad that would be similar to those done by the OpenFOAM Foundation, but I don't want to go in head first and risk breaking the Ubuntu-play-nice-agreement on Launchpad, given that placing everything on a single folder at "/opt" isn't the Debian-way of making things happen.

My advice: Document what you've done so far, at least on your wiki and we can get back to this once other higher/critical priority tasks are out of the way

In the meantime, OpenFOAM-dev is going through a lot of internal changes and syncing swak4Foam-dev right now to it as well can be a bit... distressing