On Fri, Apr 14, 2006, Noah Misch wrote: > You can use the third argument to AC_CONFIG_COMMANDS to get > the variable declared in `config.status'. Probably this: > > AC_CONFIG_COMMANDS(foo, $config_cmd, config_cmd='$config_cmd') This did the trick. > AC_CONFIG_LINKS is not so widely used, and neither is > `cccl', so it is possible that you are the first person to > face this problem. This isn't just a cccl problem, but a problem for anyone using MSVC. I guess using autoconf with MSVC pretty much implies cccl, but just in case. > I would use your essential approach involving > AC_CONFIG_COMMANDS, but rather than checking $host to decide > whether to use symbolic links for headers, write a > behavioral test. Namely, create a simple header file, make > a symbolic link to the header, and try to compile a program > that includes it by its symlinked name. If this succeeds, > use `ln -s' or `$as_ln_s'; otherwise, use `cp -p'. Good point. Changing topics a bit, the reason I have a hard coded host check is that AC_C_BIGENDIAN(ENDIAN=be,ENDIAN=le) doesn't work for me using MSVC. The test program #includes sys/params.h which MSVC can't find. config.log has: conftest.c(33) : fatal error C1083: Cannot open include file: 'sys/param.h': No such file or directory It happens to choose little endian but I didn't want to depend on that. > > Does it make sense to have the code that supports > > AC_CONFIG_LINKS use $as_ln_s instead of straight ln -s in: > > > > # Try a symlink, then a hard link, then a copy. > > ln -s $ac_rel_source $ac_dest 2>/dev/null || > > ln $srcdir/$ac_source $ac_dest 2>/dev/null || > > cp -p $srcdir/$ac_source $ac_dest || > > That is probably a reasonable clean up. It will not fix > your problem, because there is no clean way to override > $as_ln_s in `config.status'. As I think about this more, creating some links is OK. It's only those that MSVC ends up using that cause trouble. Not sure if there are enough of them that a special AC_CONFIG_LINK_DO_THE_RIGHT_THING macro is worth it. Thanks for your help. -DB _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf