You are not logged in.

#1 2020-07-26 22:50:12

Anchorman
Member
Registered: 2020-07-26
Posts: 28
Website

application data path hardcoded?

Hi, I'm busy with my first application (c++/qt) and I'm wondering what is considered to be a best practice for dealing with app data and config folder paths. I think i understand how to use Qt's QStandardPaths which checks the XDG environment variables so user app data and config is taken care of. But I'm not sure how to treat /usr/share/appname. Can i just hardcode that path since it will always be the same? And same for a PKGBUILD /usr/share/appname path?

Offline

#2 2020-07-26 23:10:34

GaKu999
Member
Registered: 2020-06-21
Posts: 124

Re: application data path hardcoded?

As far as I have seen in others...
They tend to set those up in header files (.h) that way the packager may change them at compile time.

EDIT: follow @eschwartz advice it’s a lot more precise.

Last edited by GaKu999 (2020-07-26 23:33:42)

Offline

#3 2020-07-26 23:21:57

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,534

Re: application data path hardcoded?

Hardcode the string.

If your program builds with a configuration system such as autotools or meson, you'd want to build the hardcoded string by adding the --datadir configure option to the application name, and usually storing that in a header e.g. config.h, otherwise it's up to you to figure out how to handle configuring for different OS layouts and prefixes.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#4 2020-07-26 23:37:44

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,934
Website

Re: application data path hardcoded?

If you are writing for (and only for) standard linuces, then you can just hardcode it, though even then I'd follow the next option.

If you intend for your software to function on other *nix systems, or even more "exotic" linuces, then don't hardcode it, but also don't rely on environment variables (at runtime) ... I'd call it "firmcoded" which is what eschwartz is getting at - though I disagree that this should be limited to any specific build system.  In fact, even for standard linux systems you should be doing this for PREFIX=/usr.  This is why you'll see most good software even without autotools or meson will have a make invocation as `make PREFIX=/usr`, and have some fallbacks in the Makefile, e.g.:

PREFIX    ?= /usr

This way one can override where the files will be stored by calling `make PREFIX=/opt` if they like, or somewhere else.

You can add other variables if you really want to add flexibility, e.g.:

PREFIX   ?= /usr
DATADIR  ?=  $(PREFIX)/share/appname

Though I don't know how useful this would actually be.

These variables can be passed on the compiler line and then used as macros in your code.

For example, one of my old projects included the following in the Makefile:

PROG      = foobar
VER       = 4.0
PREFIX   ?= /usr
MODULES  ?= foo bar baz
CONFFILE  = ${PREFIX}/share/${PROG}/config
DEFS      = -DPROGRAM_NAME=${PROG} -DPROGRAM_VER=${VER} -DDEFAULT_CONFIG=${CONFFILE}
DEPS      = x11 cairo poppler-glib xrandr
CFLAGS   += $(shell pkg-config --cflags ${DEPS}) ${DEFS}
LDLIBS   += $(shell pkg-config --libs ${DEPS}) -lm

This allowed the remainder of the Makefile to rely on the implicit rules for the actual building of the software, and I'd have preprocessor macros that I could use in my code for PROGRAM_NAME, PROGRAM_VER, and DEFAULT_CONFIG which would all be very easily adjusted at build time by anyone packaging the software.

Writing a decent makefile that makes packaging easy and flexible certainly doesn't require autotools (and is pretty much prevented by meson).

Last edited by Trilby (2020-07-26 23:45:03)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#5 2020-07-26 23:54:53

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,534

Re: application data path hardcoded?

Trilby wrote:

though I disagree that this should be limited to any specific build system.

I don't see how we're in disagreement here?

I specified that one will need to figure out how to handle this, unless using a specific build system that bakes the handling into the buildsystem core. In all circumstances, the application build invocation should somehow do this.

I've used sed to edit scripts in plain makefiles to contain the configured "make PREFIX=/usr", it's just a bit awkward and better handled by config.h facilities. I guess -DMACRO= works okayish, but supporting linuces like guix where bindir, libdir, datadir may not share the same prefix might be somewhat hairy.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#6 2020-07-26 23:59:28

Anchorman
Member
Registered: 2020-07-26
Posts: 28
Website

Re: application data path hardcoded?

Hey guys thanks for the great explanations! Have to think on it, learn more...

I'm using the qmake tool part of the Qt framework.

edit: also i might just want to present a binary instead of source

Last edited by Anchorman (2020-07-27 00:00:29)

Offline

#7 2020-07-26 23:59:49

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,934
Website

Re: application data path hardcoded?

eschwartz wrote:

I guess -DMACRO= works okayish, but supporting linuces like guix where bindir, libdir, datadir may not share the same prefix might be somewhat hairy.

How would it be hairy?  Just build with `make PREFIX=/whatever DATADIR=/somewhere/else` and each of these can be preprocessor macros used as needed in the code if your Makefile is sane.  Note in my excerpt, the DEFAULT_CONFIG is under PREFIX only as a default, anything specified for the DEFAULT_CONFIG on the make commandline would override this.

Also note that this was an old project and I've learned a bit since, and DATA_DIR would have been a much better variable name to use - but there's nothing different about the functionality.

Last edited by Trilby (2020-07-27 00:00:54)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

Board footer

Powered by FluxBB