cellml / libcellml-archived Goto Github PK

@codecurve (Randall) has asked for a develop branch to be created in order to use git flow.

It looks to me like the repository contains all of the gtest code including gtest's own tests. Is that really necessary? It increases the size of the repository without any particular added value.

Use case description:
Use libCellML to create a model, and serialise to XML.

This test code illustrates one way of doing this, from the caller's perspective:
https://github.com/codecurve/libcellml/blob/9a1e162fa2af0fc27808d10e0de8fc60b0899511/tests/XmlSerialisationTest.cpp#L17-L37

Note:
For various reasons, depending on how you look at it, this issue deviates from the proposed libCellML development process. Nevertheless, one of the main goals of submitting this issue now is that it will help illustrate some of the aspects of that process, for example, how BuildBot displays the results of builds and tests for the various revisions related to the corresponding pull request. This was discussed at the libCellML meeting last week. Note that the above test code already has corresponding implementation code. Build and test results are already visible under TravisCI, on a mock pull request created to illustrate this, see https://github.com/codecurve/libcellml/pull/3.

Suggestions so far:
UML
IDL (using a custom back-end to demonstrate C++ equivalent)
Text
C++ Headers and sample client code.

When building the library on Windows using cl.exe the name of the library that gets built is cellml.{lib, dll}. It should be libcellml.{lib, dll}

Part of #11

It would be good to have a way to check which branches have successful build/test statuses. Travis shows green ticks/red crosses on the branches view (that would be https://github.com/cellml/libcellml/branches).
See for example https://github.com/opencor/opencor/branches

Some progress already made:
Ubuntu 12.04 and 14.04 slaves partially done, forced builds working off this branch for now: https://github.com/codecurve/libcellml/tree/buildBotDummy01

Create an initial code stub that will set up the future development work for libCellML. This will include gtest 1.7.0 and a function version() to create a test around. This code stub will need to work with the Buildbot configuration currently in place.

Right now, the gtest code is under a folder named gtest-1.7.0. Personally, I would simply call that folder gtest, this to avoid issues many files being considered renamed (if not deleted and recreated) by git whenever gtest is upgraded to a newer version.

As a sub-task of #42, this document will describe the process for contributing new code or changes to existing code, as well as contributing new documentation or changes to existing documentation.

Windows 7 (64 bit) is all that I think is needed for now.
MSVC (whichever is currently the latest version available on ABI Build and Test Server (BaTS))

The current proposal from Randall (@codecurve) is to use the CodeSynthesis XSD tool to generate XML bindings for the serialisation and deserialisation of libCellML objects into and from XML.

Create: Create an empty validly named model from scratch and serialise it to XML. Test is that the serialised model matches manually validated XML.

(Note that compared to #31, this time the model has a name).

Should we treat compile warnings as errors? If so, the Cmake config needs to be updated accordingly.

I just came across https://github.com/codecurve/libcellml/tree/buildBotDummy01 and, sure, the code is still in its infancy, but that's the reason we probably ought to agree on some coding style. For example, looking at this version of a file, line 6 reads:

using namespace std;

of which I am not a fan at all (it can make it difficult to read some code).

Anyway, I am not claiming that I have the perfect coding style, but it might be worth looking at the coding style used in OpenCOR. As can be seen, it's pretty much the coding style used by the Qt Creator team.

Description of the process used for making contributions to the codebase, project documentation etc. Includes related documentation about things such as coding standards, how branching is used, how releases are made, etc.

First priority (I think): OS X 10.9, then 10.8 maybe. I don't think we need 10.7.
Part of issue #11.

I'm using git to version the master.cfg edits. I think it would be good if there was a "github.com/cellml/libcellml-build" repo that I could submit pull requests to etc.

The file contains buildslave passwords in plain text, so it will be necessary to blank those somehow. Not sure what the security issues are if those leak, probably not serious, since others just use the default "pass" password anyway.

The recommended way of doing this is to incorporate the Google Test source code into the product's codebase. See for example https://github.com/codecurve/libcellml/tree/basicModelUseCase01/extdep/gtest-1.7.0 for how this ends up, seemed to work well.

Making this an isolated issue and then pull request so that it can be reviewed atomically.

I'm currently using a camel-case convention for C++ source file names, (e.g. would be VariableSetHelper.h). Hugh suggested I change the case convention to all lower case (e.g. would be variablesethelper.h).

I prefer camel-case. As my example shows, all lower case makes file names look garbled (it's easy to think the first word was "variables" in the lower case example, and "helper" doesn't stand out at the end of the name, since "the" and "per" might be noticed first). The all lower case convention was strongly influenced historically by quirks when using CVS version control. I've used camel case on a C++ project consistently for 5 years a few years ago, and even using CVS, we felt it was preferable. Chaste uses a camel case convention.

What are other people's views on this?

The ABI recently adopted MPL2 for OpenCMISS-Zinc, but this was strongly influenced by the previous use of MPL1.1 (see https://tracker.physiomeproject.org/show_bug.cgi?id=3558).

Setup mailing list and e-mail notification for failed builds.

From https://github.com/cellml/libcellml/blob/master/docs/usecases.rst:

"Create: Create an [empty] model from scratch and serialise it to XML (the test is that the serialised model matches manually validated XML documents)"

See https://en.wikipedia.org/wiki/Pragma_once.
Seems like a feature that we should use, supported but the compilers that we care about.