Mike, I looks like my response sounded more negatively than I intended. I had a feeling there was something not quite right, but I have a hard time pointing it out properly.
Your solution isn't bad at all. I do consider MacPorts a different platform from OSX/Quarz just like I consider MingW and Cygwin on Windows different platforms. But I guess this doesn't matter. You make a valid point that users may have reasons unknown to us to override the default XDG_DATA_DIRS. My doubt here is if GnuCash should cater for it, especially at compile time. We do already take runtime exceptions into consideration by wrapping the XDG_DATA_DIRS environment variable. That's what the X Free Desktop specification prescribes. But again I'm only pointing at a subtle conceptual issue, which in itself can be ignored from now on. I can understand you don't want to set the environment variable in your runtime environment, nor wrap gnucash with a launcher script. By thinking and talking about this, I found another issue with the current code: discoverability. To know you can override the data dir default at compile time, you will need to read the code. You can know this is possible only through a comment and the added variable in the makefile . You already hinted at using a configure parameter. I think that's the proper fix and if done right can make the solution even more universal. Suppose you create a configure parameter --with-default-xdg-data-dirs=.... If not explicitly set, the default value for this parameter could be "/usr/local/share;/usr/share". In the makefile, the hard-coded paths can be replaced with the configure time parameter. So if the configure parameter is not set, the line that gets added to the environment file ends in "/usr/local/share;/usr/share". If you set the parameter to "/opt/local/share", the environment line will end in that. What do you think of this ? Geert On Tuesday 22 October 2013 12:09:59 Mike Alexander wrote: > --On October 22, 2013 11:26:33 AM +0200 Geert Janssens > > <[email protected]> wrote: > > I have been pondering this for a while. I don't really like this fix > > conceptually. It's MacPorts that deviates from the X Free Desktop > > standard and I don't like it that this exception in one platform > > only > > results in changed code on all other platforms. > > > > A better solution would be to detect the MacPorts platform at > > configure time, and set a proper conditional based on this, which > > is > > then used in the makefile to do some MacPorts specific overrides. > > That makes it easier for other developers to understand as well > > which particular change is for that platform only. > > > > But while thinking this alternative approach through, I concluded > > that it may even make the issue more complicated. So for now I have > > chosen to elaborate the comment in the makefile a bit to clarify > > *why* the compile time value of XDG_DATA_DIRS was added. > > I didn't think I was putting in a special case for MacPorts. Instead > I thought of it as letting people configure a special value for the > data directory search path for whatever reason. If you would rather > do it with a configure option that would be ok too (maybe better), > but this seemed reasonable and easier. Either way, it's essentially > a configure option that lets you specify the directory search path. > Is that so unreasonable? True, it's MacPorts that triggered the > need, but it's not really specific to MacPorts. > > Auto detecting MacPorts won't be easy since it can be installed > anywhere. I personally have two copies installed in different places. > One is in the normal /opt/local directory while I also have another > version installed elsewhere for testing. You also need to think of > other ways that these files might be installed in non standard > locations. Are you also going to put in special cases for Fink and > Homebrew? I happen to prefer MacPorts, but both of those have > followers too (maybe not Fink, I haven't heard much about it > recently, but certainly Homebrew does). I don't know where they > install this stuff. Of course it's also possible for someone to > install it by hand anywhere they want to. > > Mike _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
