Hi,
I wanted to try running geany from source, so an `autogen.sh` and `make` later I've got it.
I run `src/geany`, skipping `make install` since I don't want to install it, it gives me the error Failed to open file '/usr/local/share/geany/geany.glade'.
I look around and find no option or environment variable to change the data directory, (something like `-c`)
The two options I found were:
* `mkdir build && ./configure --prefix=$(pwd)/build && make && make install` * changing in https://github.com/geany/geany/blob/master/src/utils.c#L2142 `GEANY_DATADIR` to `""`
neither are good.
Is there something to do to use a source version of geany that doesn't requires modifying the source code or installing it after each make?
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/788
Whats not "good" about configuring a prefix? Geany will be installed to that prefix and can be run from `$(prefix)/bin`.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/788#issuecomment-161432957
Because I'd have to re-install it after each change to the code.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/788#issuecomment-161434802
Because I'd have to re-install it after each change to the code.
You still have to `make` after each code change anyway, but since the install to a non-system prefix doesn't need to be done with sudo, just doing `make install` will do both `make` and `make install` all in the one command.
Also I can't move it, that's less of an issue but still annoying.
Yes its not movable, and it isn't supposed to be.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/788#issuecomment-161437277
I did not know `make install` did that, that's a lot less of an issue then.
Could the data folder be treated like the config folder, a default value you can override on the command line? With that there should be only dealing with `libgeany.so.0` left to make a portable version (launched through a bash script setting relative path).
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/788#issuecomment-161560818
Geany installs things in the following relative to prefix:
bin share/application share/doc share/geany share/icons share/locale share/man lib lib/geany lib/pkgconfig
Its not just the data in share/geany.
On another note build/bin/geany --print-prefix still prints /usr/local folders,
but it works so I guess that's just a display error.
Works here if configured with a `--prefix=`
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/788#issuecomment-161581265
Closed #788.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/788#event-481255138
I see, worth asking.
Retried on a clean clone and it worked, I guess it didn't like that I changed the prefix after the first compilation.
Thanks for taking the time to answer my questions!
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/788#issuecomment-161591931
Because I'd have to re-install it after each change to the code.
Actually, you don't. You need data files to be installed, yes, but you don't need the actual executable to be. To run the in-build-directory binary, use *libtool* (as most of the code is now in *libgeany*): `libtool --mode=execute src/geany`.
Could the data folder be treated like the config folder, a default value you can override on the command line?
That wouldn't make much sense, the location of Geany's data files are not something a user is supposed to want to change depending on the runs. It's mostly part of Geany itself, not a runtime choice. Basically, if you want to do that you're doing something wrong.
With that there should be only dealing with `libgeany.so.0` left to make a portable version (launched through a bash script setting relative path).
Ah, relocatable executable on Linux. Well, fortunately for you, we do already have support for this, you just have to enable it with `--enable-binreloc` option on `./configure` call. You still have to install the resulting build, but you'll be able to move the tree around (and can very well install wherever you want, either with `--prefix` or `DESTDIR`). Binary relocation isn't very well tested though, so feel free to report issues with it.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/788#issuecomment-161657310
dear all, this original post really is about a not so well thought design of geany. I want to tell you a bit specific sitation. I am running Geany on my phone (Ubuntu Touch), you can see here: neither it does on other Linux machines by default
Now, on the phone, the most of the filesystem except ~/, is read-only. Also, is very limitted in space. Installing geany's files into /usr or anywhere outside of ~/ would be considered very expensive. So me, I installed it locally under my home. Should geany be a bit more flexible, that'd be not a problem at all. Even desktop launcher can be added to ~/.local/usr/share/applications/ instead of /usr/share/applications, and so on, HOWEVER, I had to manually ln -s my home based installation back to /usr/share/geany.
Sure, I can do this, just as I can install with a prefix to my home, but that is not convenient. That is not allowing for there to be a way of convenient automated installation to user's home directory. And basically, the ONLY portion which makes it hard, is that path containing the glider.
Just imagine how much more flexible and convenient the Geany would become if you could simply supply the path via environmental var or a command line switch.
Again, I can help myself, but I wanted to point out that in deed, Geany has a small part that limits it without clear reason for it to be that way.
Best Regards, Kris
Geany allows you to specify the installation prefix with `./configure --prefix=wherever` and Geany will install happily in `whatever` directory you specify.
elextr, you are missing a point, this is a cumbersome way of installing for people who are not used to building things, usign make, etc. Many users don't even have build-essential installed, they might not have make, or cmake or whatever else. Current design could be a tone of more accomodating and simple with a tiny fix, really,
I give you an example, I now just zip geany. WHen user downloads it and extracts, he must rund .sh script with sudo, which will ln -s folder from where he extracted (glide file) to /usr/share/geany. That is already MUCH simpler for my user than ./configure, then make install etc. But IF Geany could just implement a few additional lines of code here and there, the zip could just contain startGeany script which starts geany executable with additional env. variable or switch, and it would just fix the problem. No reconfiguring, no rebuilding or installing, no sudo.
Geany has to know where to find its data files, but it is a C program, a compiled language, so the paths can only be set at build time. You can zip up an install tree but it has to go in the same place on the target machine. A pull request that added a command line option to specify the prefix at runtime may be accepted but somebody has to make it.
@krisjace we have a build option to get a relocatable build of Geany you can move around, see my previous answer on this thread: https://github.com/geany/geany/issues/788#issuecomment-161657310
Also, if it's an important need it might be possible or even easy to add an environment variable for this (or alike) on Linux, as IIUC it works like that on OSX and Windows already, but I'd like to know the advantage over current binary relocation. Also, we *could* provide an easy-ish way of installing in the user's home, like you mentioned installing the .desktop in *~/.local/share/applications*. For that matter, doesn't an install with `--prefix=$HOME/.local/` do the whole trick? I'm not sure *~/.local* is supposed to be used that way but I'd think it would probably work.
Anyway, this thread seemed to be for people trying to run Geany from the source tree when working on it, not really for getting a relocatable build. You might be better off starting a new thread.
@b4n he has started a new thread #1702
what is geany.glide file internally? not even what it is, but how geany reads it. If Genay (C program) opens it as a file, and reads from it, then it is absolutely not a requirement that it has to be a fixed path. in a scenario, like: `FILE *fopen(const char *filename, const char *mode); ` the *filename can be anything under the sun, and same for any other higher level file access file including file streams, and what not. So I don't understand how the comment about C program, a compiled language paths can only be set at build time. The reason it has to be fixed, is because that's how someone decided to write it. It's not because it must be that way. I wish to propose a fix to the source code that would solve this in a dynamic way, rather than hardcoded static way. It would make Geany so much more versatile.
Sure `open()` can open any file, but it still has to be told the path to open, the `filename` argument, it does not search the filesystem for the file. The base of the directory tree containing `geany.glade` and all the other data files Geany needs is set at compile time in a normal Geany build, which is the normal process for Linux application builds, the base directory is located differently in a Windows or an OSX build and they have different subdirectories, [see here](https://github.com/geany/geany/blob/ca16aff4c5cb73ccb6b1c9db58389a33ad027e4f...).
As @b4n noted above, there is support for building a relocatable Linux version, but its not used regularly as far as we know since none of the normal Linux distributions provide a relocatable version, they provide a version that is located in their system directory tree.
And as I noted, it may be reasonable to support specifying a prefix as a runtime option, but Geany is a volunteer project and somebody has to do it, and #1702 is marked as an enhancement for that reason.
most portable way is to make paths relative to something known: - to where the executable is (argv[0]) - to user's home folder ($HOME env var) Lots of programs use PATH approach, where they define order at which they search path list. For example they start at (in your case) prefix, then (if not found) at relative path to user's home, then (if still failed) at the relative path to executable's directory, etc.
Yeah, the environmental variable would work well as well. And I agree with you that this is not a bug, but a feature request.
Notably I wanted to bring up a rarer example from what most people deal with in general, to defend the author of this issue. It may not be a very urgent need, but most definitely would make things easier.
I hoped that someone on this project would have free moment to review this, because I assumed that for someone who knows the structure of Geany's source code, this could be quite easy task. If you know what to look for, I imagines it almost Ctrl+F type of work, and replacing every occurrence of prefix constant in the source code with a function call, and finally writing that one function which would solve the path dynamically according to a logic like I suggested, where the prefix used to build would still have the highest priority, but on failure, there would be few other paths to check. In fact I could even myself write this kind of function, but I would need to know where to look for all the places that prefix is used, to replace it with the function call. Maybe someone would be willing to assist me, and we could have it done within next few days. I think that the value from this feature would by far exceed the time needed to implement it. Unless of course Geany code is not well structured, which I don't know.
@krisjace have you tried the current support for binary relocation?
And BTW, properly finding the Right Path™ is way trickier because `argv[0]` seldom contains a full path (not to mention it could be any kind of rubbish, it doesn't *have* to be the actual executable filename). Anyway, current relocation path code should already be handling that fairly OK.
@b4n I do not know what does current support for binary relocation mean, but if it is something that can have same effect as discussed here, I would love it! Could you tell me about it?
Btw, the argv[0] thins is sth from the top of my head, i'm sure there must be some reliable way for getting the executable's path, it's been done, must be findable with google, like: https://stackoverflow.com/questions/1528298/get-path-of-executable, or something.
Could you tell me about it?
See [above](https://github.com/geany/geany/issues/788#issuecomment-161657310).
Btw, the argv[0] thins is sth from the top of my head, i'm sure there must be some reliable way for getting the executable's path
I know there is, and it's already there in Geany, as mentioned thrice above ;)
github-comments@lists.geany.org