Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Luc Hermitte <hermitte@fr...> - 2004-11-24 15:21:41
|
Hello, I'm runing into something strange with the latest AAPs (1.068 & 1.072). I have a program made of two .cpp files. AAP correctly uses "g++ -c" on both of them, but it uses "gcc" to link the object files produced/ According to http://www.a-a-p.org/aapversionlog.html, I understand I should not have any problem since theversion 1.031, but I have. I'm running aap.bat from cygwin. My main.aap contains: UNITS = realpath SRC = cw-$*UNITS TESTS = tests/test_$*UNITS # For cygwin only! :usetool gcc :print tests::BDIR is $BDIR :print tests -> $TESTS all : $TESTS # ################################################################### # Recipes :program tests/test_realpath : tests/test_realpath.cpp cw-realpath.cpp Do I have to specify additionnal libraries, or force the filetype ? Or is it a bug ? BTW, is there an AAP compiler-plugin for vim somewhere ? -- Luc Hermitte |
From: Bram Moolenaar <Bram@mo...> - 2004-11-25 12:17:26
|
Luc Hermitte wrote: > I'm runing into something strange with the latest AAPs (1.068 & 1.072). > > I have a program made of two .cpp files. > AAP correctly uses "g++ -c" on both of them, but it uses "gcc" to link > the object files produced/ > According to http://www.a-a-p.org/aapversionlog.html, I understand I > should not have any problem since theversion 1.031, but I have. > > I'm running aap.bat from cygwin. My main.aap contains: > > UNITS = realpath > SRC = cw-$*UNITS > TESTS = tests/test_$*UNITS > > # For cygwin only! > :usetool gcc > > :print tests::BDIR is $BDIR > :print tests -> $TESTS > > all : $TESTS > > # ################################################################### > # Recipes > > :program tests/test_realpath : tests/test_realpath.cpp cw-realpath.cpp > > > Do I have to specify additionnal libraries, or force the filetype ? Or > is it a bug ? Did you try leaving out the ":usetool gcc"? That seems to avoid the problem for me. It's still a problem though, telling Aap to use gcc should still result in g++ used for linking. This patch appears to fix that: *** tools/gcc.py.orig Fri Jun 11 16:07:17 2004 --- tools/gcc.py Thu Nov 25 12:24:52 2004 *************** *** 59,64 **** --- 59,65 ---- define_action("compile_gxx", 0, """ :buildcheck $OPTIMIZE $?DEBUG + :attr {buildaction = build_gxx} $target # Need to build with $CXX :sys $GXX $CPPFLAGS $?DEFINE $?INCLUDE `cflags_normal()` $CXXFLAGS -o $target -c $source """, outtypes = ["object", "libobject"], > BTW, is there an AAP compiler-plugin for vim somewhere ? No, you can simply do: :set makeprg=aap -- ARTHUR: But if he was dying, he wouldn't bother to carve "Aaaaarrrrrrggghhh". He'd just say it. BROTHER MAYNARD: It's down there carved in stone. GALAHAD: Perhaps he was dictating. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Luc Hermitte <hermitte@fr...> - 2004-11-26 07:48:39
|
Hello, * On Thu, Nov 25, 2004 at 01:22:11PM +0100, Bram Moolenaar <Bram@...> wrote: > > I have a program made of two .cpp files. > > AAP correctly uses "g++ -c" on both of them, but it uses "gcc" to link > > the object files produced/ > > Did you try leaving out the ":usetool gcc"? Unfortunatelly, I can't. If I don't do this, aap detects VC++. As I'm writing this tool for Cygwin, and as it uses some functions specific to Cygwin, I can't use VC++. > That seems to avoid the problem for me. It's still a problem though, > telling Aap to use gcc should still result in g++ used for linking. > This patch appears to fix that: That's much better. Thanks! However, that's not perfect yet. With a build from scratch, that's fine: g++ is correctly called during the link phase. However, if I only need to (re)link (because I forget a library in the first place, or I decide to use another library), aap calls gcc and not g++. I guess we should keep in mind (/on the disk) the object files have been produced with g++ and not gcc. Anyway, as it is quite rare we only need to just link, this is not critical. ____ BTW, I notice that the error message says I have a problem into test_realpath.cpp and not tests/test_realpath.cpp. However, I do not know if it is an issue that'd better be fixed with aap, or if it must must done in a compiler-plugin, that should try to detect in which directory the file is. ____ > > BTW, is there an AAP compiler-plugin for vim somewhere ? > No, you can simply do: > :set makeprg=aap Actually, I was thinking to correctly detect some AAP error messages as error messages. For instance, I have defined compiler/aap.vim with: .... " %+A is used to accept "Do not know" in the error message set efm+=%+EAap:\ Do\ not\ know\ %m " GCC link errors (undefined reference to..) set efm+=%[%^)]%#):%f:%m .... but I was wondering if a more complete solution already exist. Thanks. -- Luc Hermitte |
From: Bram Moolenaar <Bram@mo...> - 2004-11-26 10:38:25
|
Luc Hermitte wrote: > > That seems to avoid the problem for me. It's still a problem though, > > telling Aap to use gcc should still result in g++ used for linking. > > This patch appears to fix that: > > That's much better. Thanks! > > However, that's not perfect yet. > > With a build from scratch, that's fine: g++ is correctly called during > the link phase. > However, if I only need to (re)link (because I forget a library in the > first place, or I decide to use another library), aap calls gcc and not > g++. > > I guess we should keep in mind (/on the disk) the object files have been > produced with g++ and not gcc. This is a known problem that is only partly fixed. When using build rules you can use the ">always" command block to add an attribute to the object file even when it's not build. That doesn't work for actions though, and the gcc tool uses actions. Simplest solution is to force the linker with: C_BUILD_ACTION = build_gxx > Anyway, as it is quite rare we only need to just link, this is not > critical. But I want it to work... > BTW, I notice that the error message says I have a problem into > test_realpath.cpp and not tests/test_realpath.cpp. However, I do not > know if it is an issue that'd better be fixed with aap, or if it must > must done in a compiler-plugin, that should try to detect in which > directory the file is. There should be "change directory" messages in the log file. > > > BTW, is there an AAP compiler-plugin for vim somewhere ? > > No, you can simply do: > > :set makeprg=aap > > Actually, I was thinking to correctly detect some AAP error messages as > error messages. > For instance, I have defined compiler/aap.vim with: > .... > " %+A is used to accept "Do not know" in the error message > set efm+=%+EAap:\ Do\ not\ know\ %m > " GCC link errors (undefined reference to..) > set efm+=%[%^)]%#):%f:%m > .... > but I was wondering if a more complete solution already exist. It could be useful, I suppose. If you can write a first version of an Aap compiler plugin I can include it with Vim. -- Q: Why does /dev/null accept only integers? A: You can't sink a float. /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Luc Hermitte <hermitte@fr...> - 2004-11-29 15:00:29
|
Hello, * On Fri, Nov 26, 2004 at 11:43:37AM +0100, Bram Moolenaar <Bram@...> wrote: > > However, if I only need to (re)link (because I forget a library in > > the first place, or I decide to use another library), aap calls gcc > > and not g++. > > > This is a known problem that is only partly fixed. When using build > rules you can use the ">always" command block to add an attribute to > the object file even when it's not build. That doesn't work for > actions though, and the gcc tool uses actions. > > Simplest solution is to force the linker with: > C_BUILD_ACTION = build_gxx Thanks, I'll try this. > > > > BTW, is there an AAP compiler-plugin for vim somewhere ? > > [...] > > but I was wondering if a more complete solution already exist. > > It could be useful, I suppose. If you can write a first version of an > Aap compiler plugin I can include it with Vim. I've started working on something. But it cannot be a plain aap compiler-plugin. The problem is we sometimes need to apply different filters on the output of :make. For instance: a filter for aap (or (g)make, or bjam, or scons, or ant, or ...), a filter for GCC (because the link errors are not displayed), a filter for the test unit framework used, a filter for cygwin, a filter for doxygen, ... What is the real `current_compiler' ? It is quite impossible to tell. With the cygwin compiler-plugin I'm maintaining, I've tried to answer this question. But the answer is not very good, and not really "scalable". Moreover, when we load a compiler-plugin that reset current_compiler, we need to reload compiler/cygwin.vim. It is not very handy. Any way, I have a few more things to do on the alternative solution I'm working on, and I'll make an announcement on Vim Mailing-list. -- Luc Hermitte |
From: Bram Moolenaar <Bram@mo...> - 2004-11-29 16:17:29
|
Luc Hermitte wrote: > > > > > BTW, is there an AAP compiler-plugin for vim somewhere ? > > > [...] > > > but I was wondering if a more complete solution already exist. > > > > It could be useful, I suppose. If you can write a first version of an > > Aap compiler plugin I can include it with Vim. > > I've started working on something. But it cannot be a plain aap > compiler-plugin. > The problem is we sometimes need to apply different filters on the > output of :make. For instance: a filter for aap (or (g)make, or bjam, or > scons, or ant, or ...), a filter for GCC (because the link errors are > not displayed), a filter for the test unit framework used, a filter for > cygwin, a filter for doxygen, ... The 'errorformat' option is able to handle several error formats at the same time. You can put very strict formats first, then less strict ones. The first one that matches is used. > What is the real `current_compiler' ? It is quite impossible to tell. > With the cygwin compiler-plugin I'm maintaining, I've tried to answer > this question. But the answer is not very good, and not really > "scalable". Moreover, when we load a compiler-plugin that reset > current_compiler, we need to reload compiler/cygwin.vim. It is not very > handy. It would get complicated if we make compiler-plugin-addons. You probably need a way to use the existing compiler plugins and combine the results. Since the method to combine them depends on the ordering, there is no generic solution. I suppose you could make an "aap with cygwin and doxygen" compiler plugin that loads the cygwin and doxygen compiler plugins and combines the pieces. You still need to make a plugin for every combination you use. -- Another bucket of what can only be described as human ordure hits ARTHUR. ARTHUR: ... Right! (to the KNIGHTS) That settles it! "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: Luc Hermitte <hermitte@fr...> - 2004-11-29 17:37:24
|
(x-post between aap and vim MLs, fu2 on vim@...) * On Mon, Nov 29, 2004 at 05:23:17PM +0100, Bram Moolenaar <Bram@...> wrote: > > > > > > BTW, is there an AAP compiler-plugin for vim somewhere ? > > > > [...] > > > > but I was wondering if a more complete solution already exist. > > > > > > It could be useful, I suppose. If you can write a first version > > > of an Aap compiler plugin I can include it with Vim. > > > > I've started working on something. But it cannot be a plain aap > > compiler-plugin. > > The problem is we sometimes need to apply different filters on the > > output of :make. For instance: a filter for aap (or (g)make, or > > bjam, or scons, or ant, or ...), a filter for GCC (because the link > > errors are not displayed), a filter for the test unit framework > > used, a filter for cygwin, a filter for doxygen, ... > The 'errorformat' option is able to handle several error formats at > the same time. You can put very strict formats first, then less > strict ones. The first one that matches is used. 'errorformat' is not the problem. As long as I don't want to have options (/various levels) like what we have with LaTeXSuite. The main problem is with 'makeprg'. I do not know why, but I must explicitly use aap.bat, and the outputs must be filtered with an external script (initially sed, now a perl script). And there are other tools out there that I plan to use, like the one that decrypt error messages involving C++'s STL. > > What is the real `current_compiler' ? It is quite impossible to > > tell. With the cygwin compiler-plugin I'm maintaining, I've tried > > to answer this question. But the answer is not very good, and not > > really "scalable". Moreover, when we load a compiler-plugin that > > reset current_compiler, we need to reload compiler/cygwin.vim. It is > > not very handy. > > It would get complicated if we make compiler-plugin-addons. Not really with the framework I am working on. For instance, I have the add-ons into {rtp}/compiler/BTW/. And I load them with: :BTW set aap " can be done at any time :BTW add gcc " order may matter, because of the external filters :BTW add boost-TU " order may matter ... :BTW add cygwin " order may matter ... I plan to add priorities, add `remove', be able to change the options for gcc (without reloading the other definitions), enhance the support for buffer-local filters (when working with several projects using different tools) > You probably need a way to use the existing compiler plugins and > combine the results. Since the method to combine them depends on the > ordering, there is no generic solution. I am thinking about a way to extract meaningful information from pre-existing compiler-plugins ; i.e. 'errorformat' and 'makeprg'. > I suppose you could make an "aap with cygwin and doxygen" compiler > plugin that loads the cygwin and doxygen compiler plugins and combines > the pieces. You still need to make a plugin for every combination you > use. That is what I find not scalable. I'd rather have policies (filters) that I can load and unload independently. Moreover there would have two different kinds of compiler-plugins. The core ones, made for one specific tool, and the ones used on specific projects. Unfortunatelly, the core-ones tend to use some kind of anti-reinclusion guards, making difficult to mix let's say fortran and C error messages. -- Luc Hermitte |