Re: Baked-in paths
On 15 March 2010 01:30, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Sun, 14 Mar 2010, Reuben Thomas wrote: I imagine this question has been asked before, but searching the archives, the net and the manual didn't help me with the following: I have a C program which loads some scripts at runtime. These are stored in datadir (e.g. /usr/local/share/prog). But I also want to be able to run the program from its build directory. At the moment I bake in the relevant path; I imagine that for make install I have to rebuild the binary, baking in the installation path, having baked the build directory path in a normal make. Is there a recommended way to deal with this situation? I use environment variables to tell the test programs where the source directory is. This does indeed sound like a security weakness. If the test programs are executed via a test script, then the test script can format program arguments appropriately. There are no program arguments for this case, because the scripts are part of the program: the program is written partly in C, partly in Lua. If you also test using your main installable program, you need to take care that any embedded environment variables don't cause a security problem. That is why I was asking whether automake would let me make make install build another version with a different path baked in. It is sounding as though the answer is no, in which case I may just end up baking the Lua into the C program, since that is straightforward, but it does seem to be a weakness of the autotools for this case. -- http://rrt.sc3d.org
Re: Baked-in paths
On Sun, Mar 14, 2010 at 11:29 PM, Reuben Thomas r...@sc3d.org wrote:
I have a C program which loads some scripts at runtime. These are
stored in datadir (e.g. /usr/local/share/prog). But I also want to be
able to run the program from its build directory.
We have some similar situations but failed to find one solution
working well in all cases.
For unit tests, we sometimes (run-time) re-configure the test
object. This might be as simple as:
static const char *configPath_ = /usr/local/share/prog;
const char *getConfigPath(void) { return configPath_); }
void setTestConfigPath(void) { configPath_ = .; }
If the application has something like:
int main(int argc, char *argv[]) { return appXyzMain(argc, argv); }
the test can call appXyzMain with an argv containing `--data-dir=.' option.
Then there are cases where it seems suited to have a list of
directories where to search:
const char *paths[] { ./tests/, /usr/local/share/, /usr/share };
Some tools (helper scripts) even `guess' if they run from a
sandbox (e.g. by looking if a file Makefile exists in same
directory or compare $argv[0] with @prefix@, but all this seems
to be tricky and surely not portable).
oki,
Steffen
Re: Baked-in paths
Hi Reuben, On 3/14/2010 4:29 PM, Reuben Thomas wrote: I imagine this question has been asked before, but searching the archives, the net and the manual didn't help me with the following: I have a C program which loads some scripts at runtime. These are stored in datadir (e.g. /usr/local/share/prog). But I also want to be able to run the program from its build directory. At the moment I bake in the relevant path; I imagine that for make install I have to rebuild the binary, baking in the installation path, having baked the build directory path in a normal make. Is there a recommended way to deal with this situation? The software packages I've worked on have all been complex enough to warrant a configuration file in the system config directory (/etc, whatever), which is locked down by virtue of its location. Since only the administrator can change the contents of a file in $(sysconfdir), it's not a security issue. But what this does allow me to do is generate an installed configuration file with reasonable default paths derived from $(prefix) variables. At the same time, I bake default paths into the application, which are also derived from $(prefix) variables and passed on the compiler command line. This allows me to run without a config file, as long as the app is properly installed. Finally, the key benefit is that I can run my program in test mode by supplying an appropriate config file on the command line (./program -c testconfig.ini). I love the flexibility this system provides, and I don't see any security issues with it, unless your program must be run as root in order to do what it needs to do. In that case, it's not safe to execute it during make check anyway. But it can be executed during make installcheck. John
Re: Public header files
* Jef Driesen wrote on Sat, Mar 13, 2010 at 11:21:45PM CET: On 13/03/10 11:34, Ralf Wildenhues wrote: You are using a AC_CONFIG_FILES now instead of a AC_CONFIG_HEADERS. That's fine per se, but config files are updated unconditionally by config.status, meaning that the updated timestamp might cause more rebuilds than necessary. I used AC_CONFIG_FILES because I had the impression that was more powerfull than AC_CONFIG_HEADERS, in the sense that I can do more than just defining values. True, and a good rationale for using it. For instance, I prefer to have: typedef foobar ticks_t; instead of: #define ticks_t foobar It might be possible to achieve the same with AC_CONFIG_HEADERS, but I don't know how. I had a look at a number of projects to see how they did this, and they used AC_CONFIG_FILES. Well, you can usually emulate such things with a helper #define and conditional #if/#ifdef code in the manually written header. The next thing I want to add is a MYLIB_VERSION_REVISION, that contains some info from the SCM system (e.g. a svn revision number, a git sha1 hash). When building a (not yet released) development version of my code, it would be useful to know the exact revision. There's been quite some prior discussion and examples of this in the list archives, but a perfect solution still would require some changes to Automake. I suppose you are referring to solutions like this: m4_define([mylib_version_revision],m4_esyscmd([my_revision_script])) where the revision script fetches the revision from the SCM system, or from a version file when using tarballs. Well, that solution has the disadvantage that a revision change causes a full autotools and configure rerun, but yes, that is one suboptimal solution. Cheers, Ralf
