Alan Manuel Gloria: > A heads-up though: the aclocal on guile-1.6 has GUILE_PROGS require > guile and guile-config. On my workplace's system, strangely enough > guile is installed but *not* guile-config. So at least on certain > really old Red Hat / Fedora (not sure which, I'll have to ask the > sysad) distros, it might fail. > > (not that this is *not* an issue - I intend to just copy > readable/color-of-the-bikeshed-issue.scm verbatim into the tool I'll > eventually build for my workplace, the license allows that anyay (^^). > For another I don't intend to follow the usual site directory for > Guile either)
Okay. BTW, I renamed (readable sweet-impl) to (readable kernel), for your bikeshedding pleasure :-). > I don't know what guile-config is for though - if it's needed for > GUILE_SITE_DIR then you definitely need guile-config then. .... > Also, for unsweeten and sweeten_header, Guile 1.6 (IIRC) needs a \ > metaswitch to properly read options in the script file. Yay 1.6! > > Of course, #! only supports 2 items, so you should probably use: > > #! @GUILE@ \ > -L "@LIBRARY_DIRECTORY@" -s > > # @WARNING_MESSAGE@ > > !# Agree. Done. > But now you can't use my-subst. You *could* replace it with > unsweeten.in and sweeten_header.in, and add to > AC_CONFIG_FILES([Makefile src/unsweeten src/sweeten_header]) or some > such - GUILE_PROGS automatically includes @GUILE@ in an AC_SUBST. And > of course @LIBRARY_DIRECTORY@ needs to be changed to @GUILE_SITE@ (or > is that @GUILE_SITE_DIR@?) Sure I can use my-subst, I just have to modify it to also replace GUILE. Easy enough. Done. It's silly, but it's a short script & it makes sure that the substitutions happen at the right time. Reusing AC_CONFIG_FILES is easy enough, but it would do it at configure time, not at build time (whups). If a *lot* of variables need to be replaced I'd restructure, but for a few it's not worth it. > Guile 1.6 does not have a -L option AFAICT. You need to set > GUILE_LOAD_PATH for that - in fact, it's probably best to override > GUILE_LOAD_PATH so that crazy crackers can't make you suddenly load a > module you weren't expecting. Well, the *lack* of -L is annoying. I don't have a 1.6 to test with, though. The resetting of a PATH-like variable only needs to happen at a trust boundary. There's no trust boundary here (if there was, it'd be upstream from us, so no issue). > unsweeten still has code to augment the %load-path, but this is no > longer necessary since you're already putting it in a -L switch (or, > err, rather putting the correct location into GUILE_LOAD_PATH) Well, could always getenv() something. > I'll try to see what I can do this weekend to make it compatible with > 1.6, and check for incompatibilities with 2.0. Okay. --_ David A. Wheeler ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
