Re: Improve Autoconf MSVC support
On 2024-06-03 16:19, Antonin Décimo wrote: >> I guess you are not using Automake, because both of these problems >> should be solved automatically by Automake. Automake replaces $CC >> with invocations through a wrapper script that knows how to translate >> -l and -o options into MSVC equivalents (such as -Fo/-Fe). >> >> If you don't want to use Automake I suggest at least using this >> wrapper script in your project. > > I'm not using Automake but I'll consider it. Were you referring to cccl? No, Automake has a script called "compile" (I don't know if this cccl is related or not) which is automatically installed into packages using Automake if they use AC_PROG_CC to find a C compiler. Cheers, Nick
Re: Improve Autoconf MSVC support
Hi Nick, Thank you for your reply! > I guess you are not using Automake, because both of these problems > should be solved automatically by Automake. Automake replaces $CC > with invocations through a wrapper script that knows how to translate > -l and -o options into MSVC equivalents (such as -Fo/-Fe). > > If you don't want to use Automake I suggest at least using this > wrapper script in your project. I'm not using Automake but I'll consider it. Were you referring to cccl? https://github.com/swig/cccl I'll try it, thanks. > > MSVC doesn't have a version flag but will report its version if > > called directly. > > I don't understand why this is important. It's not important, but reading the config.log file, I see that configure is trying multiple version flags one after the other, that MSVC doesn't recognize. Maybe I just misunderstood and configure is trying to tell whether the compiler executable runs? -- Antonin
Re: Improve Autoconf MSVC support
Hi Antonin,
On 2024-06-03 12:05, Antonin Décimo wrote:
> Dear maintainers,
>
> I've listed three little problems I've had using MSVC and Autoconf.
> They stem from MSVC not accepting the same parameters from the usual
> unix tools. I wonder if these could be fixed. I'm happy to help with
> testing.
>
> Note that MSVC supports both `/param` and `-param` styles; the former
> being used in documentation, but I think we should prefer the latter
> for Unix compatibility (compilers might interpret the `/param` style
> as paths).
Yes, using the slash form of the options is fraught with peril (in
particular, MSYS looks for command line arguments that look like
UNIX-style absolute filenames and modifies them by prepending
drive letters). Fortunately the hyphen form works fine.
> - `AC_SEARCH_LIBS`: the macro prepends `-llibrary` to `LIBS` to look
> for a function in a library. MSVC doesn't recognize these arguments,
> and expects `library.lib` at the end of its invocation.
> Also applies to `{AC,AH}_CHECK_LIB`.
>
> - Output file
>
> MSVC will stop supporting `/o`/`-o` to select its output file and is
> already warning about it.
[...]
I guess you are not using Automake, because both of these problems
should be solved automatically by Automake. Automake replaces $CC
with invocations through a wrapper script that knows how to translate
-l and -o options into MSVC equivalents (such as -Fo/-Fe).
If you don't want to use Automake I suggest at least using this
wrapper script in your project.
The combination of -c with -o is not even portable amongst POSIX
hosts (the POSIX-standard compiler commands leave the results of
this combination explicitly unspecified).
> - Version flag
>
> MSVC doesn't have a version flag but will report its version if
> called directly.
I don't understand why this is important.
Cheers,
Nick
Re: Improve Autoconf MSVC support
Thanks for your helpful comments. Would you be up to writing and testing Autoconf patches to support MSVC better? I don't use MSVC and so would not be good for that. Thanks.
Improve Autoconf MSVC support
Dear maintainers,
I've listed three little problems I've had using MSVC and Autoconf.
They stem from MSVC not accepting the same parameters from the usual
unix tools. I wonder if these could be fixed. I'm happy to help with
testing.
Note that MSVC supports both `/param` and `-param` styles; the former
being used in documentation, but I think we should prefer the latter
for Unix compatibility (compilers might interpret the `/param` style
as paths).
- `AC_SEARCH_LIBS`: the macro prepends `-llibrary` to `LIBS` to look
for a function in a library. MSVC doesn't recognize these arguments,
and expects `library.lib` at the end of its invocation.
Also applies to `{AC,AH}_CHECK_LIB`.
- Output file
MSVC will stop supporting `/o`/`-o` to select its output file and is
already warning about it.
> cl : Command line warning D9035 : option 'o' has been deprecated
and will be removed in a future release
MSVC uses the `/Fo` option to specify the object file name (in
conjunction with the `/c` option), and the `/Fe` option to specify
the executable file name.
https://learn.microsoft.com/en-us/cpp/build/reference/fo-object-file-name?view=msvc-170
https://learn.microsoft.com/en-us/cpp/build/reference/fe-name-exe-file?view=msvc-170
- Version flag
MSVC doesn't have a version flag but will report its version if
called directly.
> cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.41.33901 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
Best regards,
-- Antonin
