GetAppPath vs. DetermineExecutablePath

[mandrav]

So we are hardcoding /usr/local, /opt or whatever? Strange, I haven't noticed...

Yes, and yes.

But anyway, I am sick of endlessly justifying every 6 lines of code that I ever wrote. Do whatever you want, and if you think SELFPATH is so much of a better solution then for pity's sake use it...

I didn't expect this kind of answer, not based on my questions on why some things have changed like this :roll:.

I really don't give a damn if binreloc is used or not. What I care about is for things to work. If you believe your solution is better/smaller/faster, just use it. But don't react like that when I ask questions about it because I 'm trying to understand why some things stopped working. And if I don't understand then somebody else will have to fix them. And that somebody will have to be you because it's only you who know what has changed.
If that's what you want, here's a bug report for you: This used to work fine and now it's broken...

PS: next time please put a note in your forum posts stating whether I am allowed to ask anything about it or not. Strangely enough I thought that I had that right but now it seems I was wrong...

[Der Meister]

Did anyone test revision 3245 and newer on Linux with '-prefix=/opt/codeblocks' or something similar as parameter for the configure-script?
Because Code::Blocks failes to find its ressources and plugins here. It tries to find them in '/usr/local/share/codeblocks' which obviously does not exist here. It should use '/opt/codeblocks' instead.

[thomas]

Did anyone test revision 3245 and newer on Linux with '-prefix=/opt/codeblocks' or something similar as parameter for the configure-script?
Because Code::Blocks failes to find its ressources and plugins here. It tries to find them in '/usr/local/share/codeblocks' which obviously does not exist here. It should use '/opt/codeblocks' instead.

It probably does not work with earlier revisions, either. Have you tried --prefix=/opt ever since 3194?
I would be very surprised if it worked using 3244.

[Der Meister]

I never built Code::Blocks without this option. I'm not quite sure what revisions I used recently, but at least revision 3230 was working for me (used this one to find the problem with the splash screen on Linux).

[mandrav]

I never built Code::Blocks without this option. I'm not quite sure what revisions I used recently, but at least revision 3230 was working for me (used this one to find the problem with the splash screen on Linux).

That's true. I happen to have 3230 around (in linux) and --prefix works fine with it.

[thomas]

Well, that's magic then, because it cannot work.
For --prefix= to work, you need to call wxStandardPathsBase::SetInstallPrefix(), which I forgot to add in 3194.

Plugins and resources are found (or not found) using wxStandardPathsBase::Get().GetDataDir() since 3194. This has not changed in 3245, and the changes in 3245 are more or less unrelated to the actual plugin/resource paths (short of a ?: that sets user = global in "relocated" mode).
My much-discussed /proc/self code affects GetAppPath(), but not the other ones.

wxStandardPathsBase::Get().GetDataDir() returns a global variable that you can set using above function (which we aren't doing), and which it fills it when empty. For that, it appends the application's name to wxStandardPathsBase::Get().GetPrefix().
That latter function, yes you guessed it, uses readlink("/proc/self/exe") to get the application's location, removes everything after the last "/bin/", and finally hardcodes /usr/local/ as a fallback in case anything goes wrong.

[mandrav]

No magic whatsoever. The app sets the datapath and this was honoured before whether you believe it or not.
With the latest changes though, ConfigManager::InitPaths() is called only when the first ConfigManager::GetFolder() is made, which in turn overwrote the datapath setting with whatever ConfigManager felt was right. There, that was the actual problem.

[afb]

I'll continue to patch both versions (GetAppPath/DetermineExecutablePath) for Darwin/Solaris.