[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AC_CONFIG_LINKS and MSVC
From: |
David Byron |
Subject: |
RE: AC_CONFIG_LINKS and MSVC |
Date: |
Fri, 14 Apr 2006 15:43:39 -0700 |
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