Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

exporter.export #383

Closed
vhuber opened this issue Jun 13, 2014 · 6 comments
Closed

exporter.export #383

vhuber opened this issue Jun 13, 2014 · 6 comments

Comments

@vhuber
Copy link
Contributor

vhuber commented Jun 13, 2014

Why there is no

if(boption("exporter.export"))

at the beginning of each save() function (exporter*)

@prudhomm
Copy link
Member

partly lazyness, partly because it is not quite nice

@vhuber
Copy link
Contributor Author

vhuber commented Jun 15, 2014

I do not understand: I guess that option was defined to that purpose.

@prudhomm
Copy link
Member

or the user can use it

@prudhomm
Copy link
Member

if ( boption( "exporter.export" ) )
{
 ///  exporter code here

}

@vhuber
Copy link
Contributor Author

vhuber commented Jun 16, 2014

Of course the user can do it, but the purpose of that option is ambiguous (to my mind).
Maybe we can explicitly create levels of options or find a way to make it clear to everyone

  • for the user dev (--functions.*, --exporter.export ...)
  • for tuning purpose (--mesh1d.localisation.nelt-in-leaf-kdtree)
  • for master only (--fieldsplit-0.fieldsplit-1.lsc.sub-ksp-maxit-reuse)

@prudhomm
Copy link
Member

of course, the idea of creating --help and --help-lib. In time, lib will be split into various domains like for example the one you mention. This needs to be discussed to avoir changing things too often.

@prudhomm prudhomm closed this as completed Jan 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants