search

OpenCDE / opencde

OpenCDE Desktop
http://www.opencde.org
Other
18 stars 3 forks source link

app-defaults in random location, makefiles a rat's nest #20

Open idunham opened 12 years ago

idunham commented 12 years ago

The current (HEAD) buildsystem is a tangle, with 3 files to drive it: a "Makefile" that isn't, a BSDmakefile for FreeBSD, and a GNUmakefile for Linux. FSH support is similarly tangled. Further, app-defaults still doesn't land in the right place. Since I created the mess, I thought I'd fix it. The buildsystem branch is my cleanup, and is currently complete.

arcfide commented 12 years ago

Thanks, I'll try to get a look at this soon.

arcfide commented 12 years ago

I've taken a quick look, and I would like some explanation of why it is still ask complicated as it is. There are two new files there. Why do we have them out of the main Makefile? Do we expect user's to edit them? Indeed, why not have all of this in a single Makefile that has a top section commented clearly for user's to modify? This would simplify things even further, and make configuration and building more straightforward.

arcfide commented 12 years ago

Looking a little more closely at this, i think it would be better if we did not use the filesystem for our conditionals. is there a way to get our Makefile to make these conditional jumps without needing to have this extra element? I think there is, but I have not done this sort of Make magic in a while.

idunham commented 12 years ago

There is a way to do it in FreeBSD make and a way to do it in GNU make. Unfortunately, neither understands the other one's way. Try running gmake -F BSDmakefile or freebsd-make -F GNUmakefile if you doubt it. (I implemented that logic, then found it unportable)

Of course, neither way works on the other make versions, like pmake, bmake (variants of NetBSD make), heirloom make, (Open)Solaris make... This way, we can expect it to work with any make version on any *NIX/BSD/Linux variant.

The point of a separate file is that we must both enable a compiler flag (-DFSH) and change a couple paths for installation. If only one is done, the result will not run; this way, they have to work to break things . I guess the ideal solution would be to search both /etc/opencde and $PREFIX/opencde all the time, and just change the install path with an option in config.Mk. This is a change in libopencde, IIRC (grep -r for FSH).

arcfide commented 12 years ago

Thanks for the larger explanation. Could you detail why we need the compiler flag? There should be no dependency on the location of the app-defaults file in any of the code.

idunham commented 12 years ago

dtpanel calls a function in libopencde to take care of opening menus.ini. This function looks in ~/.opencde/APPNAME/ for various config files (other than app-defaults); if they are not found, it will instead look in the systemwide install directory, and (IIRC) copy them over (not sure about the last part). By default this is hard-coded to system("basename argv[0]") + "/../etc/opencde/" + APP; FSH support is #ifdef FSH ... and uses /etc/opencde/APP instead It should probably look in one directory. then the other (I'd look in /etc/opencde first because it involves fewer system calls, but...) -DFSH is equivalent to #define FSH

arcfide commented 12 years ago

Hrm, it sounds like the real problem is the hard coded file path. Why not have a define like:

#ifndef ETCDIR
#define ETCDIR ../../etc/opencde/" ...
#endif

And then use a Makefile variable to do the definition? The idea of having two hard-coded paths when we should be able to determine the right place at compile time is a little annoying.

idunham commented 12 years ago

Why not have a define like:

#ifndef ETCDIR
#define ETCDIR ../../etc/opencde/" ...
#endif

And then use a Makefile variable to do the definition? The idea of having two hard-coded paths when we should be able to determine the right place at compile time is a little annoying.

karsten wanted to allow relocation of binaries (IE, you can buld a tree, and install the same binaries in /opt/opencde per LSB addon specs, /usr for a distro, /usr/local for FreeBSD/GNU standards, /usr/pkg like pkgsrc, $HOME/.local for local installs...) I'd go for replacing the "#ifdef FSH" with

ifdef ETCDIR

= ETCDIR + "/opencde" ... #else #endif Note that ETCDIR should not include the "/opencde/" part, to act fairly standard (I think some autopackage-type scripts rely on ETCDIR=/etc not making a mess of the configuration folders)
arcfide commented 12 years ago

Another solution is to just symlink /etc/opencde to the right place. I think that if you want to create a location independent installation, you can still go with the ETCDIR, but just make the path relative. Otherwise, if you don't want to make things relocatable, then just give ETCDIR a different value. It works either way.