Skip to content

Break fileIO ApplicationsLib dependency#1138

Merged
endJunction merged 2 commits intoufz:masterfrom
endJunction:BreakFileIOApplicationsLibDependency
Apr 19, 2016
Merged

Break fileIO ApplicationsLib dependency#1138
endJunction merged 2 commits intoufz:masterfrom
endJunction:BreakFileIOApplicationsLibDependency

Conversation

@endJunction
Copy link
Copy Markdown
Member

@endJunction endJunction commented Apr 12, 2016

Follow up of #1133. This PR adds only the one commit [DE] Break ApplicationLib dependency.

The dependency is caused by usage of ProjectData::addMesh by XmlGspInterface.
Unfortunately the programming of that class and its parents, the XMLInterface and XMLQtInterface is not as separate as it could be, therefore the current solution can be seen as a quickfix.

Clean solution would be, for example, a separation of the reader and the writer parts of the XMLInterface(s) and to use standalone functions for qt's xml validation.

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 13, 2016

Jenkins: OGS-6/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Win-PRs/1449/

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 13, 2016

Jenkins: OGS-6/Linux-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Linux-PRs/1565/

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 13, 2016

Jenkins: OGS-6/Gui/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Win-PRs/1426/

Comment thread FileIO/XmlIO/Qt/XmlGspInterface.cpp Outdated
XmlGspInterface::XmlGspInterface(
GeoLib::GEOObjects& geoObjects,
std::vector<MeshLib::Mesh*> const& mesh_vector,
std::function<void(MeshLib::Mesh* const)> add_mesh_callback)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

move it: &&

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This prevents the Data Explorer from loading anything except geometries and meshes from a project?!

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it does not. It is only separating circular dependency of the FileIO and ApplicationsLib. The code for reading is not touched, so everything what was read should behave exactly the same. Only the place where the mesh is added to project has moved.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if the project file reader has no knowledge of ProjectData but only of GeoObjects + the mesh vector it can only store the related information. I don't doubt that everything works fine at the moment but the next step after reorganising the project file reader would be reading/writing boundary conditions which would then require another parameter, I think? Maybe we could talk about this tomorrow or on friday? (maybe together with Tom as would probably be involved in the next stage)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rinkk, I can understand your concerns. But if we keep all parts of ProjectData in here, soon FileIO will also depend on ProcessLib (for BCs). Probably that shouldn't be.
Maybe a different approach would be to move some of the parsing code to the DE directory. Do you think, that's feasible?
E.g., the following case checking code probably should be done in some DE class.

if (file_node.compare("geo") == 0)

Maybe at some point one could even use the constructor that is provided with ProjectData to read the *.prj (if we remove std::abort() 😄).
That's at least what I can say after a discussion with @endJunction.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe it's not good idea to mix core parts and application layers together. How about provide separate FileIO for ApplicationLib? Current FileIO can be used to provide read and write of basic data, e.g. geo and mesh.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with Nori. If planning a major cleanup of the FileIO/ApplicationsLib separation of the business logic and the actual reading of the data would be a good goal.

We shall have a 30min discussion tomorrow.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or to make it consistent for all libs, we can create FileIo for each lib, e.g. geolib/fileio, meshlib/fileio

@chleh
Copy link
Copy Markdown
Collaborator

chleh commented Apr 13, 2016

Last commit (f044d58) looks good. Just make it compile. 👍

@rinkk
Copy link
Copy Markdown
Member

rinkk commented Apr 13, 2016

As a general question: Why does the DataExplorer need to be decoupled from FileIO?

Comment thread FileIO/XmlIO/Qt/XmlGspInterface.cpp Outdated
// MSH
const std::vector<MeshLib::Mesh*> msh_vec = _project.getMeshObjects();
for (std::vector<MeshLib::Mesh*>::const_iterator it(msh_vec.begin()); it != msh_vec.end(); ++it)
for (std::vector<MeshLib::Mesh*>::const_iterator it(_mesh_vector.begin());
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not shorter and more readable: for (auto const* mesh : _mesh_vector)? ✅

@endJunction
Copy link
Copy Markdown
Member Author

The data explorer is not decoupled from FileIO, and actually nothing is decoupled. The circular dependency of ApplicationLib and FileIO is removed.

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 13, 2016

Jenkins: OGS-6/Gui/Mac-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Mac-PRs/1433/

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 13, 2016

Jenkins: OGS-6/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Win-PRs/1454/

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 13, 2016

Jenkins: OGS-6/Gui/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Win-PRs/1431/

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 13, 2016

Jenkins: OGS-6/Gui/Gui-Linux-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Gui-Linux-PRs/1540/

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 13, 2016

Jenkins: OGS-6/Linux-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Linux-PRs/1570/

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 14, 2016

Jenkins: OGS-6/Mac-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Mac-PRs/1451/

@bilke
Copy link
Copy Markdown
Member

bilke commented Apr 14, 2016

Jenkins test this please.

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 14, 2016

Jenkins: OGS-6/Gui/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Win-PRs/1432/

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 14, 2016

Jenkins: OGS-6/Gui/Gui-Linux-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Gui-Linux-PRs/1541/

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 14, 2016

Jenkins: OGS-6/Gui/Mac-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Mac-PRs/1434/

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 14, 2016

Jenkins: OGS-6/Linux-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Linux-PRs/1571/

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 14, 2016

Jenkins: OGS-6/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Win-PRs/1455/

@rinkk
Copy link
Copy Markdown
Member

rinkk commented Apr 14, 2016

Would it help to create a seperate data holder object for the Data Explorer in, e.g. BaseLib, and keep everything else as it is?
What I need (and what ProjectData originally was) is a container for storing all data relevant to the currently processed project. OGS, and especially the Data Explorer has 20 or more input formats and I would like to keep these seperate from the application itself. In addition, some of said formats can hold geometry or meshes so that a clear dinstinction what library they'd belong to is not necessarily clear.

@endJunction
Copy link
Copy Markdown
Member Author

In the discussion we came to the following two steps:

  • This PR will be merged in order to be able to use shared libraries asap.
  • A "project data" structure---different from the current ProjectData---suitable for the data explorer and used by the FileIO will be introduced, thus breaking the dependency of the FileIO and the ApplicationsLib.

Comment thread MathLib/CMakeLists.txt
logog
)

if(METIS_FOUND)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TOdo for later, not now: we shouldnt always link metis and lapack just because Cmake could find them. there should be a flag like OGS_USE_METIS.
Noted in https://github.com/ufz/ogs/issues/1142

@norihiro-w
Copy link
Copy Markdown
Collaborator

i haven't checked ProjectData stuff, but other changes look nice. just a question: you removed logog dependency from most of libs. is it because BaseLib depends on it?

@endJunction
Copy link
Copy Markdown
Member Author

The logog is removed as dependency from most libs but BaseLib, because the default behaviour for linking is transitive. See cmake doc.

I'm yet figuring out, what the minimum specification is, such that all links fine w/o overhead. But first resolving the circular dependencies bugs.

@norihiro-w
Copy link
Copy Markdown
Collaborator

thanks for the explanation!

@endJunction
Copy link
Copy Markdown
Member Author

Update: Initially I thought the EnableSharedLibs PR would be much easier, but first I need to break the circular deps. So this is now a stand-alone PR not based on shared libs but set up as a prerequisite for them.
This is actually reviewed and all previous comments are incorporated.

@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Apr 17, 2016

Build finished.

@norihiro-w
Copy link
Copy Markdown
Collaborator

👍

Adding a callback for adding project meshes and pass additional arguments to
XmlGspInterface constructor.
@endJunction endJunction merged commit 5ab2033 into ufz:master Apr 19, 2016
@endJunction endJunction deleted the BreakFileIOApplicationsLibDependency branch April 19, 2016 10:03
@ogsbot
Copy link
Copy Markdown
Member

ogsbot commented Jun 19, 2020

OpenGeoSys development has been moved to GitLab.

See this pull request on GitLab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants