Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Hi Gary, Den 2010-06-22 14:53 skrev Gary V. Vaughan: In this case, Peter, would you point me at the followup patches that need this preliminary prep work? I had a poke around in your git branch but couldn't (quickly) figure out where this is going... and without that it's hard to do a sane review. I've said it elsewhere, but here are more details in case you missed it: In _LT_LINKER_SHLIBS([TAGNAME]) _LT_TAGVAR(compile_tag, $1)=-TC and in _LT_LANG_CXX_CONFIG([TAG]) _LT_TAGVAR(compile_tag, $1)=-TP As found in commit 9c848f1e8acdf435d019aa80f3f0b0aeb45613f7 Add MSVC support. Cheers, Peter
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
On 23 Jun 2010, at 13:56, Peter Rosin wrote: Hi Gary, Hi Peter, Den 2010-06-22 14:53 skrev Gary V. Vaughan: In this case, Peter, would you point me at the followup patches that need this preliminary prep work? I had a poke around in your git branch but couldn't (quickly) figure out where this is going... and without that it's hard to do a sane review. I've said it elsewhere, It seems our posts crossed, but I saw the other response too, thanks. but here are more details in case you missed it: In _LT_LINKER_SHLIBS([TAGNAME]) _LT_TAGVAR(compile_tag, $1)=-TC and in _LT_LANG_CXX_CONFIG([TAG]) _LT_TAGVAR(compile_tag, $1)=-TP As found in commit 9c848f1e8acdf435d019aa80f3f0b0aeb45613f7 Add MSVC support. Actually, this is kind of backwards for how I would have done things... normally I try to build the infrastructure in the earlier patches, and then slot in the enhancements that build on it later. But no matter really, as long as you're happy to point forward to subsequent patches that rely on seemingly non-functional additions from earlier patches as we work through the merge. If you'd rather follow Ralf's suggestions from earlier in this thread, and move the hinting process into Automake, then I'll be delighted. Otherwise, pending the outcome of that discussion, if you're still happy that your earlier branch was already going in the right direction, feel free to commit this to master. I haven't made any testsuite reruns for this part of the review, since this patch is so innocuous I'll wait until I'm reviewing something more contentious first... I am assuming, of course, that you have made a successful testsuite run with this patch merged to guard against syntax errors or the like (successful testsuite run on Linux or Mac is perfectly fine at this point). Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Hi Ralf, Den 2010-06-22 22:16 skrev Ralf Wildenhues: * Peter Rosin wrote on Tue, Jun 22, 2010 at 03:07:30PM CEST: So, it's not a bit deal for me to have this one dangling. But that said, it is nice to fire and forget... This one is not fire and forget. I can live with fire, but not with forget, because the right place to fix this issue is not within Libtool. The issue is similar to what Fortran solves with AC_FC_SRCEXT in Autoconf, whose result automake uses to to put right before the source file name. Here, the same could be done for -Tc or -Tp, respectively. One difference is that the flag is not specific to the file name extension, just to the language. What am I missing? Ah yes, someone would need to call such a macro; probably the cleanest way would be call it from AC_PROG_CC. One cheaper way could be to hard-code known extensions into 'compile' now, but that means this script is getting more uglier. For those that didn't know, we have these cl options to play with: /Tpsource file compile file as .cpp /Tcsource file compile file as .c /TP compile all files as .cpp /TC compile all files as .c (but using - instead of / to not go insane immediately) cl will interpret any files with unknown extensions as object files. It does know about .c and .cpp, but falls over on .cc .c++ .cxx etc. It will treat .C files as plain old C since it doesn't care about filename case. My patches went with -TP/-TC. IIUC AC_FC_SRCEXT outputs FCFLAGS_ext which can be used as this: foo.o: foo.f90 $(FC) -c $(FCFLAGS) $(FCFLAGS_f90) '$(srcdir)/foo.f90' which is a closer match for -Tp/-Tc but I don't know if the missing space is going to be an issue for other potential future users of the macro. I.e. can you portably store a trailing space in a makefile variable so that the following is a usable construct for something that needs e.g. say CXXFLAGS_cc=-cpp ? $(CXX) -c $(CXXFLAGS) $(CXXFLAGS_cc)'$(srcdir)/foo.cc' Another issue that doesn't translate directly from the Fortran case is that one extension we /may/ want to cover is .c++, and I don't expect that CXXFLAGS_c++ is very good as a variable name. To me, it seems way easier to do it in compile. Can it take the clutter? (which would be something like this added to the proposed compile script) *.C | *.cc | *.cpp) func_file_conv $1 set x $@ -Tp$file shift ;; *.c) func_file_conv $1 set x $@ -Tc$file shift ;; And yes, I should apologize for not seeing this four years ago ... You might have, I just don't remember it (I did search and couldn't find anything, but that's hardly water tight evidence...). I do have vague memories of a discussion about which of -TP/-TC and -Tp/-Tc to use though so don't feel too bad. But that might have been before I proposed the patch? Anyway, that doesn't matter. I'm not adding these references about what happened when in these messages to make everyone apologize and generally feel bad. I add them to simplify review and to save others from digging in history that I have already been through. Cheers, Peter
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Den 2010-06-23 07:39 skrev Gary V. Vaughan: What happened 4 years ago? (pr-msvc-support branched on 2008-08-02) I started working in this problem space ca 2003-2004, and proposed a very rough patch 2005. Ralf help immensely and it all got into a much better shape. 2006 was the first time my patches showed up in a form that resembles what's in the pr-msvc-support branch. Ralf created the branch in 2008 with the intention that the work should not bit-rot completely. But having the branch in the official repo has made me reluctant to rebase, refactor and otherwise change things even though it is not correct or tasty enough, so the branch has not really worked from my point of view. Cheers, Peter
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Den 2010-06-22 22:16 skrev Ralf Wildenhues: This one is not fire and forget. I can live with fire, but not with forget, because the right place to fix this issue is not within Libtool. So, let's skip this for libtool and assume that it is fixed elsewhere, at least for now. It's not vital and the libtool testsuite uses .cpp anyway so it should not light up the whole thing with FAILED making other problems hard to spot. Cheers, Peter
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
On 6/23/2010 3:57 AM, Peter Rosin wrote: For those that didn't know, we have these cl options to play with: /Tpsource file compile file as .cpp /Tcsource file compile file as .c /TP compile all files as .cpp /TC compile all files as .c (but using - instead of / to not go insane immediately) Yes, cl accepts switches with either '/' or '-' introductory characters. For our purposes, it's almost required to use '-' rather than the Microsoft standard '/', because for native use, our shell is an msys shell, and MSYS does interesting things when exec() or spawn() functions are called... In this case, one interesting thing is that MSYS has a heuristic that any command line arguments that start with '/' are presumed to be (posix) paths, and if the to-be-exec'ed program is a native one, then the argument will be converted to a DOS path. E.g. /Tpbob.cpp == C:/pwd/Tpbob.cpp /TcC:/path/to/fred.cpp == C:/TcC:/path/to/fred.cpp /TP == C:/TP /TC == C:/TC This is clearly bad...and can be avoided by always using '-' (or by 'doubling' the leading slash, which turns off MSYS's path conversion logic: msys path.cc: // // Multiple forward slashes are treated special, // Remove one and return for the form of //foo or ///bar // but just return for the form of //server/share. // but (a) this would break for //TcC:/a/path because the fact that there are additional '/' other than the leading sequence means that the first, doubled pair would not be translated into a single leading slash, and (b) that's just more than we want to deal with, here, since '-' will do what we want.) My patches went with -TP/-TC. OTOH, //TP and //TC would work just as well, with an MSYS shell. But I think your choice (both using '-' and using the capital variants of these switches) is a good one, because... To me, it seems way easier to do it in compile. Can it take the clutter? (which would be something like this added to the proposed compile script) *.C | *.cc | *.cpp) func_file_conv $1 set x $@ -Tp$file shift ;; *.c) func_file_conv $1 set x $@ -Tc$file shift ;; There is one problem with the above. -Tcrel/path/to/file will work OK, and -Tcfile-in-curdir will work. Also -TcC:/dos/path/to. But -Tc/abs/posix/path/to/file won't, because...well, another MSYS heuristic. MSYS knows about some of gcc's path introductory switches, like -I and -L, and will convert -I/posix/path/to/inc -L/posix/path/to/lib to -IC:/msys/1.0/posix/path/to/inc -LC:/msys/1.0/posix/path/to/lib if the gcc in question is a native application (like MinGW gcc is) [Technically, this works for any single letter option. But MSYS *doesn't* know about cl's path introductory switches like -Tc or -Tp that have more than a single letter. msys path.cc: // // Check for single letter option with a // path argument attached, eg -I/include */ // So, for the path translation heuristics to work, MSYS *needs* a space between -Tc and /the/path, so that /the/path can be detected as an absolute posix path by itself. Unfortunately, I *think* cl requires that there be NO space between -Tc and C:/the/path. Ditto -Fo, etc. Unless you've already manually converted the path in question from posix to win32 form, the -Fo, -Tc, -Tp, and similar options won't work. The preceding is all just background, because I think Peter's patch *does* do a manual path conversion for any paths that appear together with these options. It costs an extra fork for each one, but...short of teaching the MSYS DLL about cl's huge list of multi-char options, I think Peter's approach is the only rational choice. -- Chuck
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
* Peter Rosin wrote on Wed, Jun 23, 2010 at 09:57:54AM CEST:
For those that didn't know, we have these cl options to play with:
One reference: http://msdn.microsoft.com/en-us/library/19z1t1wy.aspx
My patches went with -TP/-TC. IIUC AC_FC_SRCEXT outputs FCFLAGS_ext which
can be used as this:
foo.o: foo.f90
$(FC) -c $(FCFLAGS) $(FCFLAGS_f90) '$(srcdir)/foo.f90'
which is a closer match for -Tp/-Tc but I don't know if the missing space
is going to be an issue for other potential future users of the macro. I.e.
can you portably store a trailing space in a makefile variable so that the
following is a usable construct for something that needs e.g. say
CXXFLAGS_cc=-cpp ?
$(CXX) -c $(CXXFLAGS) $(CXXFLAGS_cc)'$(srcdir)/foo.cc'
It is possible I think, with something like
empty =
trailing_space = foo $(empty)
But for packages using automake, this is not an issue at all. Look at
automake.in, it controls how per-language compile lines will look like:
$sourceflags{'.' . $suffix} = '$(FCFLAGS_' . $suffix . ') '
Note the trailing space, that gets expanded at automake run time, not at
make run time.
Another issue that doesn't translate directly from the Fortran case is that
one extension we /may/ want to cover is .c++, and I don't expect that
CXXFLAGS_c++ is very good as a variable name.
Flattening of the suffix is trivial in automake, too.
This would all just be an issue for packages using Autoconf but not
Automake, writing compile lines in Makefile.in files themselves.
To me, it seems way easier to do it in compile. Can it take the clutter?
(which would be something like this added to the proposed compile script)
*.C | *.cc | *.cpp)
func_file_conv $1
set x $@ -Tp$file
shift
;;
*.c)
func_file_conv $1
set x $@ -Tc$file
shift
;;
Are you sure there can't be another argument matching these endings?
-Dfoo=bar.cc
Does cl accept any options with separated arguments, i.e., $2 has the
argument to $1? We may have to start parsing these right.
Other than that, I don't see problems with the 'compile' hack approach.
Please keep this change (and associated testsuite additions) separate
from the other patch though, for clarity.
I'm not adding these references about what happened when in these messages
to make everyone apologize and generally feel bad. I add them to simplify
review and to save others from digging in history that I have already been
through.
Yeah, and that's good, too.
Thanks,
Ralf
MSVC: MSVC needs a hint to force it to compile either as C or C++.
Next patch in the MSVC series...
This is
MSVC needs a hint to force it to compile either as C or C++.
abfb96f4c44b3e38fcf960c876e17fc252e9712c
and the relevant part of
patch msvc-documentation.patch
06cfce005204bb8ca212aadab38b38c0202ea04e
with @var changed to @code
This was originally suggested by Ralf here:
http://lists.gnu.org/archive/html/libtool-patches/2006-02/msg00067.html
and first posted here (I think):
http://lists.gnu.org/archive/html/libtool-patches/2007-07/msg00042.html
If you want to see how it is intended to be used, look in
Add MSVC support
9c848f1e8acdf435d019aa80f3f0b0aeb45613f7
I don't remember any feedback on this patch, but it seems pretty
benign to me.
Cheers,
Peter
2010-06-22 Peter Rosin p...@lysator.liu.se
MSVC needs a hint to force it to compile either as C or C++.
* libltdl/m4/libtool.m4: Add tag variable compile_tag to
enable tag specific compiler options that are bad in the
linking phase.
* libltdl/config/ltmain.m4sh: Add the tag specific options
to the compile command line.
* doc/libtool.texi (libtool script contents): Document
new variable.
commit 3d2d3ef899cb7e83d5d77dea695e13dfeb80ee7f
Author: Gary V. Vaughan gary@gnu.org
Date: Mon Jun 21 19:49:29 2010 +0700
Ensure getopts.m4sh is compatible with Autoconf-2.61 and newer.
* libltdl/config/getopt.m4sh (m4_chomp): Ensure this macro is
implemented even if Autoconf's m4sugar.m4 doesn't provide it.
(m4go_expand): New macro based on Autoconf-2.64 m4_expand. Use
it everywhere incase m4sugar.m4 doesn't have an implementation.
(m4_ifnblank): Replace all uses with m4_ifval, which was
available long before m4_ifnblank was introduced.
diff --git a/ChangeLog b/ChangeLog
index 9bc84c8..18e346d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2010-06-21 Gary V. Vaughan gary@gnu.org
+
+ Ensure getopts.m4sh is compatible with Autoconf-2.61 and newer.
+ * libltdl/config/getopt.m4sh (m4_chomp): Ensure this macro is
+ implemented even if Autoconf's m4sugar.m4 doesn't provide it.
+ (m4go_expand): New macro based on Autoconf-2.64 m4_expand. Use
+ it everywhere incase m4sugar.m4 doesn't have an implementation.
+ (m4_ifnblank): Replace all uses with m4_ifval, which was
+ available long before m4_ifnblank was introduced.
+
2010-06-20 Ralf Wildenhues Ralf.Wildenhues@gmx.de
Fix clean mode for HP-UX 11.31 sh.
diff --git a/libltdl/config/getopt.m4sh b/libltdl/config/getopt.m4sh
index 44cf727..031402c 100644
--- a/libltdl/config/getopt.m4sh
+++ b/libltdl/config/getopt.m4sh
@@ -44,8 +44,46 @@ m4_include([general.m4sh])m4_divert_push([KILL]) -*- Autoconf -*-
# All internal macros begin with `m4go_'.
m4_pattern_forbid([^_?m4go_])
+
+## --- ##
+## 1. Backwards compatibility. ##
+## --- ##
+
+# m4_chomp(STRING)
+#
+# m4_chomp was not introduced until Autoconf-2.64. Currently we
+# only use it indirectly via m4go_expand, below. This implementation
+# is taken from Autoconf-2.65.
+m4_ifndef([m4_chomp],
+[m4_define([m4_chomp],
+[m4_format([[%.*s]], m4_index(m4_translit([[$1]], [
+/.], [/ ])[./.], [/.]), [$1])])])
+
+# m4go_expand(ARG)
+#
+# M4SH_GETOPTS wants to pass unbalanced parentheses to m4_expand to
+# build the branches of a shell `case' statement. That is only
+# supported by the implementation of m4_expand in Autoconf-2.64 and
+# newer. Since we want to be compatible back to at least
+# Autoconf-2.62, reimplement our own 2.64 based m4_expand in the
+# m4go_ namespace so that we can be compatible with Autoconf versions
+# supporting either semantic.
+m4_define([m4go_expand],
+[m4_chomp(_$0([$1
+]))])
+
+m4_define([_m4go_expand], [$0_([$1], [(], -={($1)}=-, [}=-])])
+
+m4_define([_m4go_ignore])
+
+m4_define([_m4go_expand_],
+[m4_if([$4], [}=-],
+ [m4_changequote([-={$2], [)}=-])$3m4_changequote([, ])],
+ [$0([$1], [($2], -={($2$1)}=-, [}=-])_m4go_ignore$2])])
+
+
## - ##
-## 1. Low level string manipulation. ##
+## 2. Low level string manipulation. ##
## - ##
# m4go_slice(STRING, BEGIN, END)
@@ -96,10 +134,10 @@ m4_define([m4go_slice],
# to turn them off for the duration.
# 6. Finally, we need to requote the result to account for the quotes
# we probably stripped. m4_quote() doesn't handle commas well, so
-# we use m4_expand() to requote without losing whitespace after any
-# embedded commas.
+# we use m4go_expand() to requote without losing whitespace after
+# any embedded commas.
m4_define([m4go_trimn],
-[m4_changecom()m4_expand([m4go_slice([$1], m4_bregexp(m4_translit([$1],[
+[m4_changecom()m4go_expand([m4go_slice([$1], m4_bregexp(m4_translit([$1],[
[/,()]], [// ]), [[^/]]), m4_bregexp(m4_translit([$1], [
[/,()]], [/ /]), [/*$]))])[]m4_changecom([#])])
@@ -119,7 +157,7 @@ m4_define([m4go_unindent
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Ooops, exported the wrong thing from git...
Sorry for the noise. Here's the intended patch
Cheers,
Peter
commit 1e1a3cb447ee0d725d6cd8249358d9d5595a039b
Author: Peter Rosin peda@lysator.liu.se
Date: Tue Jun 22 11:07:22 2010 +0200
MSVC needs a hint to force it to compile either as C or C++.
* libltdl/m4/libtool.m4: Add tag variable compile_tag to
enable tag specific compiler options that are bad in the
linking phase.
* libltdl/config/ltmain.m4sh: Add the tag specific options
to the compile command line.
* doc/libtool.texi (libtool script contents): Document
new variable.
diff --git a/ChangeLog b/ChangeLog
index 18e346d..2320bb8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2010-06-22 Peter Rosin peda@lysator.liu.se
+
+ MSVC needs a hint to force it to compile either as C or C++.
+ * libltdl/m4/libtool.m4: Add tag variable compile_tag to
+ enable tag specific compiler options that are bad in the
+ linking phase.
+ * libltdl/config/ltmain.m4sh: Add the tag specific options
+ to the compile command line.
+ * doc/libtool.texi (libtool script contents): Document
+ new variable.
+
2010-06-21 Gary V. Vaughan gary@gnu.org
Ensure getopts.m4sh is compatible with Autoconf-2.61 and newer.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 7ae2c66..94d9268 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -5910,6 +5910,11 @@ Whether libtool should build static libraries on this system. Set to
@samp{yes} or @samp{no}.
@end defvar
+@defvar compile_tag
+Add tag specific option for the compiler. Normally disabled (i.e.
+@code{compile_tag} is empty).
+@end defvar
+
@defvar compiler_c_o
Whether the compiler supports the @option{-c} and @option{-o} options
simultaneously. Set to @samp{yes} or @samp{no}.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index a325e27..d484694 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -854,6 +854,10 @@ func_mode_compile ()
pic_mode=default
fi
+if test -n $compile_tag; then
+ base_compile=$base_compile $compile_tag
+fi
+
# Calculate the filename of the output object if compiler does
# not support -o with -c
if test $compiler_c_o = no; then
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index b93dd0c..e5f2459 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -5347,6 +5347,8 @@ _LT_TAGDECL([], [prelink_cmds], [2],
[Commands necessary for linking programs (against libraries) with templates])
_LT_TAGDECL([], [file_list_spec], [1],
[Specify filename containing input files])
+_LT_TAGDECL([], [compile_tag], [1],
+[Add tag specific option for the compiler])
dnl FIXME: Not yet implemented
dnl _LT_TAGDECL([], [thread_safe_flag_spec], [1],
dnl[Compiler flag to generate thread safe objects])
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Hi Peter, Thanks for your continued work on this. On 22 Jun 2010, at 16:35, Peter Rosin wrote: MSVC needs a hint to force it to compile either as C or C++. * libltdl/m4/libtool.m4: Add tag variable compile_tag to enable tag specific compiler options that are bad in the linking phase. * libltdl/config/ltmain.m4sh: Add the tag specific options to the compile command line. * doc/libtool.texi (libtool script contents): Document new variable. But compile_tag is never set, so the patch is a NOP! If that happens with a later patch in your series, please roll all the compile_tag machinery into a single commit. If this has to be fudged into the libtool tag settings by hand to support MSVC (or some other nefarious means I'm missing), then please document that. Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
On 6/22/2010 7:54 AM, Gary V. Vaughan wrote: But compile_tag is never set, so the patch is a NOP! If that happens with a later patch in your series, please roll all the compile_tag machinery into a single commit. But what if that later patch, in order to work correctly, also requires additional prep work? You're possibly opening up a spiderweb of inter-dependencies between patches. I could easily see a series of nop patches, each of which is small and easily reviewed in isolation, but all of which are necessary for a single, final do it patch. You might be asking, in effect, for do it + all the nops to be rolled together and presented at once -- in a large, complex, difficult to review patch. Peter has already split his mega patch into small, easily digestible chunks with minimal inter-dependencies. Let's not second guess his decomposition... -- Chuck
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Hi Gary, Den 2010-06-22 13:54 skrev Gary V. Vaughan: But compile_tag is never set, so the patch is a NOP! If that happens with a later patch in your series, please roll all the compile_tag machinery into a single commit. If this has to be fudged into the libtool tag settings by hand to support MSVC (or some other nefarious means I'm missing), then please document that. It happens in a later patch. Way-back-when I did it that way to not get one big unwieldy monster patch. I.e. first add all parts needed, then a final patch that just switches it all on. But as it happens, this is the last one of the enabler patches. The others have already been commited, deferred or have been fed to the bit bucket by the proposed changes to the compile script in automake. So, it's not a bit deal for me to have this one dangling. But that said, it is nice to fire and forget... Also note that if you want to see how this patch is going to be used, look at commit 9c848f1e8acdf435d019aa80f3f0b0aeb45613f7 Add MSVC support. (But the do it patch as Chuck named it is not last, more stuff have happened since, but with that one and the compile script changes we will have basic support.) Cheers, Peter
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Hi Chuck,On 22 Jun 2010, at 19:10, Charles Wilson wrote:On 6/22/2010 7:54 AM, Gary V. Vaughan wrote:But compile_tag is never set, so the patch is a NOP!If that happens with a later patch in your series, please roll allthe compile_tag machinery into a single commit.But what if that later patch, in order to work correctly, also requiresadditional prep work? You're possibly opening up a spiderweb ofinter-dependencies between patches.I could easily see a series of "nop" patches, each of which is small andeasily reviewed in isolation, but all of which are necessary for asingle, final "do it" patch. You might be asking, in effect, for "doit" + "all the nops" to be rolled together and presented at once -- ina large, complex, difficult to review patch.Peter has already split his mega patch into small, easily digestiblechunks with minimal inter-dependencies. Let's not second guess hisdecomposition...That's a good point. But on the other side of the coin I don't wantto blindly "okay" a series of NOP patches into master without understandingfirst where we are going.In this case, Peter, would you point me at the followup patches that needthis preliminary prep work? I had a poke around in your git branch butcouldn't (quickly) figure out where this is going... and without that it'shard to do a sane review.Cheers,--Gary V. Vaughan (g...@gnu.org)
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Hi Peter, * Peter Rosin wrote on Tue, Jun 22, 2010 at 03:07:30PM CEST: Den 2010-06-22 13:54 skrev Gary V. Vaughan: But compile_tag is never set, so the patch is a NOP! If this has to be fudged into the libtool tag settings by hand to support MSVC (or some other nefarious means I'm missing), then please document that. It happens in a later patch. Way-back-when I did it that way to not get one big unwieldy monster patch. I.e. first add all parts needed, then a final patch that just switches it all on. So, it's not a bit deal for me to have this one dangling. But that said, it is nice to fire and forget... This one is not fire and forget. I can live with fire, but not with forget, because the right place to fix this issue is not within Libtool. The issue is similar to what Fortran solves with AC_FC_SRCEXT in Autoconf, whose result automake uses to to put right before the source file name. Here, the same could be done for -Tc or -Tp, respectively. One difference is that the flag is not specific to the file name extension, just to the language. What am I missing? Ah yes, someone would need to call such a macro; probably the cleanest way would be call it from AC_PROG_CC. One cheaper way could be to hard-code known extensions into 'compile' now, but that means this script is getting more uglier. And yes, I should apologize for not seeing this four years ago ... Comments? Thanks, Ralf
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Hallo Ralf, Peter, On 23 Jun 2010, at 03:16, Ralf Wildenhues wrote: * Peter Rosin wrote on Tue, Jun 22, 2010 at 03:07:30PM CEST: Den 2010-06-22 13:54 skrev Gary V. Vaughan: But compile_tag is never set, so the patch is a NOP! If this has to be fudged into the libtool tag settings by hand to support MSVC (or some other nefarious means I'm missing), then please document that. It happens in a later patch. Way-back-when I did it that way to not get one big unwieldy monster patch. I.e. first add all parts needed, then a final patch that just switches it all on. So, it's not a bit deal for me to have this one dangling. But that said, it is nice to fire and forget... This one is not fire and forget. I can live with fire, but not with forget, because the right place to fix this issue is not within Libtool. The issue is similar to what Fortran solves with AC_FC_SRCEXT in Autoconf, whose result automake uses to to put right before the source file name. Here, the same could be done for -Tc or -Tp, respectively. One difference is that the flag is not specific to the file name extension, just to the language. What am I missing? Ah yes, someone would need to call such a macro; probably the cleanest way would be call it from AC_PROG_CC. One cheaper way could be to hard-code known extensions into 'compile' now, but that means this script is getting more uglier. And yes, I should apologize for not seeing this four years ago ... What happened 4 years ago? (pr-msvc-support branched on 2008-08-02) Comments? I won't pretend to understand all the interactions between the various components of Automake, but I certainly *do* like the simplification that wrapper scripts always seem to provide (especially when compared to poking the equivalent functionality into dozens of places over the several hundred KB of already torturous libtool code). The compile script by comparison is tiny and easy to understand, and if we can easily add some of the MSVC support into compile without obfuscating it, then that seems like a no-brainer to me. Further if we're already using a similar idiom for Fortran compilers, then I also think it's a good idea to reuse an already tried and tested idiom for this problem rather than invent and debug a new one. To temper all of this, Peter is the one doing all the work here, and as long as there is no negative impact on the existing supported platforms of Autotools, I'm happy to help get the support into our codebase in whatever form he thinks will be easiest for him to apply and maintain. Cheers, -- Gary V. Vaughan (g...@gnu.org)
