Remove need to use OPENMODELICAHOME

[Martin Sjölund]

We already use /proc/self in Linux and similar in OSX.
By adding the same for Windows, we can remove the need to have this environment variable mess things up:
​http://stackoverflow.com/questions/4841546/safely-get-path-to-running-executable-in-windows-api

The only open question is how to handle this in OSX as the OMEdit.app needs to be able to find the omc executable. With dynamic linking, this is sort of resolved (as OSX hard-codes the paths of .dylib, so you cannot moved things around freely anyway). And even without, the OMEdit.app can keep a hardcoded path to omc (as it does today).

[Adrian Pop]

I would never do this for Windows.
It would make things worse as you cannot configure which omc you want to use.

[Martin Sjölund]

I said remove the NEED to use it. It would still be an override.

I think it's good if you click C:\OpenModelica1.8.1\bin\OMEdit.exe, it would load omc 1.8.1 if OPENMODELICAHOME was unset. And if you went to 1.9.0\bin\OMEdit.exe, it would load omc 1.9.0. It makes more sense than changing env.vars every time you want to use the other one...

[Adrian Pop]

OPENMODELICAHOME and OPENMODELICALIBRARY is always set by the installer.
Do you want to never set those and somehow deduct
them automatically when we run one of the clients?
That should be possible, but I think it would make
things more opaque and confuse users.

Also, this would need to be back-ported to previous
releases if we get rid of these variables.

[Martin Sjölund]

Replying to adrpo:

OPENMODELICAHOME and OPENMODELICALIBRARY is always set by the installer.
Do you want to never set those and somehow deduct
them automatically when we run one of the clients?
That should be possible, but I think it would make
things more opaque and confuse users.

That's what we do on Linux :)

Also, this would need to be back-ported to previous
releases if we get rid of these variables.

Maybe. Or just use .bat-files to set the env.var before you call those. You anyway need to do this today if you want to use several versions on the same computer.

[Adrian Pop]

I know that's what we do on Linux but if we use .bat
files to set these variables then things are the same
as before. You just set the correct OPENMODELICAHOME
and OPENMODELICALIBRARY if you want to run another
version, this is what I do.

Anyhow, I'll think about it as it would be good to
easily run different versions of OpenModelica on the
same system without having to make .bat files.

[Martin Sjölund]

It would at least work without env.vars for all new versions of OpenModelica. I think we should add code like the one above to read a default OPENMODELICAHOME if it was not set as env.var. If it's not set, we just crash now anyway, right? Would be step 1, and then we can fix the rest later. OMEdit is not up to par yet anyway (only uses hard-coded paths).

[Adrian Pop]

As far as I know we don't crash right now.
See Main.setWindowsPaths where we really check that things are OK or we exit.
But that's for OMC, I don't know about OMEdit.

Agreed that we could do more checks.
At start OMEdit can check if OPENMODELICAHOME
points to the omc in the OMEdit directory or not,
and warn about it. If OPENMODELICAHOME is not set
set it to that directory where OMEdit (and omc) is.

[Martin Sjölund]

  const char *path = SettingsImpl__getInstallationDirectoryPath();
  if (path == NULL)
    RML_TAILCALLK(rmlFC);

I think you just exit if it's unset on Windows. With:

failure(_ = Settings.getInstallationDirectoryPath());
        print("Error: OPENMODELICAHOME was not set.\n");
        print("  Read the documentation for instructions on how to set it properly.\n");
        print("  Most OpenModelica release distributions have scripts that set OPENMODELICAHOME for you.\n\n");

Much better to just assume it's this executable. Actually, I think probably the omc executable should ignore OPENMODELICAHOME and just assume it is placed in $OPENMODELICAHOME/bin/omc. And maybe only use this for OMEdit.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

The milestone of this ticket has been reassigned to "Future".

If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.

If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".

In both cases, a short informative comment would be welcome.