Thread: [A-A-P-develop] 3 aap suggestions
Brought to you by:
vimboss
From: Pavol J. <ju...@pa...> - 2005-11-25 18:02:28
|
Hello, I have been using aap (version 1.079) for some time and I am quite impressed. However, there are few things that could be improved: (1) aap is not using correct linker when linking c++ objects. Example: # main.aap contains single line ":program hello : hello.cpp" # clean build works $ aap Aap: g++ -MM hello.cpp > build-Linux2_6_12_1_1381_FC3/hello.cpp.aap Aap: g++ -O2 -c -o build-Linux2_6_12_1_1381_FC3/hello.o hello.cpp Aap: g++ -O2 -o hello build-Linux2_6_12_1_1381_FC3/hello.o # but building from objects does not $ rm hello $ aap Aap: cc -O2 -o hello build-Linux2_6_12_1_1381_FC3/hello.o build-Linux2_6_12_1_1381_FC3/hello.o(.text+0x12): In function `main': : undefined reference to `std::cout' ... Can this be fixed so that aap uses g++ as a linker when linking c++ objects? (2) :toolsearch raises exception when it cannot find some tool. I am running my code on 2 different architectures - on the group linux box and on university x86_64 high-performance linux cluster. The later system has Intel c-compiler, which is not available on the group machine. I created new tools file, intelcc.py, put it to the ~/.aap/tools directory on cluster and used :toolsearch intelcc gcc in my main.aap. I thought this would work on both systems and aap would choose gcc if intelcc was not defined. However aap raises an exception and dies if it cannot find intelcc.py (3) when ~/.aap/tools contains some files, aap ignores default tools in /usr/local/share/aap/tools doc/aap/ref-commands.html#cmd-usetool says that 3 directories are searched for compiler tools, and they must contain __init__.py. In fact only one directory is searched. Python uses for all imports the first package directory that contains __init__.py, therefore aap can find only tools in ~/.aap/tools, and the remaining directories are ignored. I think the solution would be to add all tools directories into sys.path (maybe only temporarily inside toolsearch or usetool functions) or to use lower-level python import statements, so that all tools directories could be searched. Is it possible to fix these 3 issues? Thanks, Pavol |
From: Bram M. <Br...@mo...> - 2005-11-26 14:25:49
|
Pavol Juhas wrote: > I have been using aap (version 1.079) for some time and I am quite > impressed. However, there are few things that could be improved: > > (1) aap is not using correct linker when linking c++ objects. > > Example: > # main.aap contains single line ":program hello : hello.cpp" > # clean build works > $ aap > Aap: g++ -MM hello.cpp > build-Linux2_6_12_1_1381_FC3/hello.cpp.aap > Aap: g++ -O2 -c -o build-Linux2_6_12_1_1381_FC3/hello.o hello.cpp > Aap: g++ -O2 -o hello build-Linux2_6_12_1_1381_FC3/hello.o > # but building from objects does not > $ rm hello > $ aap > Aap: cc -O2 -o hello build-Linux2_6_12_1_1381_FC3/hello.o > build-Linux2_6_12_1_1381_FC3/hello.o(.text+0x12): In function `main': > : undefined reference to `std::cout' > ... > > Can this be fixed so that aap uses g++ as a linker when linking c++ objects? This is a known problem: Object files as such don't have an indication that they come from a C++ file. It works when Aap also does the compilation, because an attribute is added to the object file then. A solution would be to store the attributes for the object file in the signature file AAPDIR/sign. That's not a small change though... > (2) :toolsearch raises exception when it cannot find some tool. > > I am running my code on 2 different architectures - on the group linux > box and on university x86_64 high-performance linux cluster. The later > system has Intel c-compiler, which is not available on the group > machine. I created new tools file, intelcc.py, put it to the > ~/.aap/tools directory on cluster and used > > :toolsearch intelcc gcc > > in my main.aap. I thought this would work on both systems and aap would > choose gcc if intelcc was not defined. However aap raises an exception > and dies if it cannot find intelcc.py What is the exception? > (3) when ~/.aap/tools contains some files, aap ignores default tools in > /usr/local/share/aap/tools > > doc/aap/ref-commands.html#cmd-usetool says that 3 directories are > searched for compiler tools, and they must contain __init__.py. In > fact only one directory is searched. Python uses for all imports the > first package directory that contains __init__.py, therefore aap can > find only tools in ~/.aap/tools, and the remaining directories are > ignored. I think the solution would be to add all tools directories > into sys.path (maybe only temporarily inside toolsearch or usetool > functions) or to use lower-level python import statements, so that all > tools directories could be searched. Aap already uses sys.path to do this. I can't say why it doesn't work for you... If you know a bit of python, look in the Commands.py file, the aap_toolsearch() function. -- hundred-and-one symptoms of being an internet addict: 214. Your MCI "Circle of Friends" are all Hayes-compatible. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://www.ICCF.nl /// |
From: Pavol J. <ju...@pa...> - 2005-11-27 01:13:35
|
On Sat, Nov 26, 2005 at 03:26:33PM +0100, Bram Moolenaar wrote: > > Pavol Juhas wrote: > > > I have been using aap (version 1.079) for some time and I am quite > > impressed. However, there are few things that could be improved: > > > > (1) aap is not using correct linker when linking c++ objects. > > ... > > > > Can this be fixed so that aap uses g++ as a linker when linking c++ objects? > > This is a known problem: Object files as such don't have an indication > that they come from a C++ file. It works when Aap also does the > compilation, because an attribute is added to the object file then. > > A solution would be to store the attributes for the object file in the > signature file AAPDIR/sign. That's not a small change though... Another solution may be to make aap remember what kind of files it checked to determine if the objects in AAPDIR are up-to-date. Even when hello.o exists, aap has to check before linking if it is consistent with hello.cpp. Does aap know at that stage that it would use g++ to update hello.o if it is old? If yes, maybe it can keep that information and use g++ for linking. > > > (2) :toolsearch raises exception when it cannot find some tool. > > > > I am running my code on 2 different architectures - on the group linux > > box and on university x86_64 high-performance linux cluster. The later > > system has Intel c-compiler, which is not available on the group > > machine. I created new tools file, intelcc.py, put it to the > > ~/.aap/tools directory on cluster and used > > > > :toolsearch intelcc gcc > > > > in my main.aap. I thought this would work on both systems and aap would > > choose gcc if intelcc was not defined. However aap raises an exception > > and dies if it cannot find intelcc.py > > What is the exception? ImportError: No module named intelcc. I think aap should catch and ignore this exception and continue searching for other tools. Exception should be raised when :toolsearch cannot find any tool at all. > > (3) when ~/.aap/tools contains some files, aap ignores default tools in > > /usr/local/share/aap/tools > > > > doc/aap/ref-commands.html#cmd-usetool says that 3 directories are > > searched for compiler tools, and they must contain __init__.py. In > > fact only one directory is searched. Python uses for all imports the > > first package directory that contains __init__.py, therefore aap can > > find only tools in ~/.aap/tools, and the remaining directories are > > ignored. I think the solution would be to add all tools directories > > into sys.path (maybe only temporarily inside toolsearch or usetool > > functions) or to use lower-level python import statements, so that all > > tools directories could be searched. > > Aap already uses sys.path to do this. I can't say why it doesn't work > for you... If you know a bit of python, look in the Commands.py file, > the aap_toolsearch() function. The problem is that when python loads a module from package, it will always use the first package directory that it finds in sys.path. Therefore if ~/.aap/tools contains __init__.py and intelcc.py, aap can only find intelcc, because python would always import from ~/.aap/tools. A solution is to use the imp module which allows more control over what is imported. Attached are patches for problems (2) and (3) with respect to the latest cvs version. They seem to fix both issues. Cheers, Pavol |
From: Pavol J. <ju...@pa...> - 2005-11-27 01:18:18
Attachments:
usetoolsearch.patch
|
Sorry, I forgot to attach patch. Pavol |
From: Bram M. <Br...@mo...> - 2005-11-28 11:17:17
|
Pavol Juhas wrote: > > > I have been using aap (version 1.079) for some time and I am quite > > > impressed. However, there are few things that could be improved: > > > > > > (1) aap is not using correct linker when linking c++ objects. > > > > ... > > > > > > Can this be fixed so that aap uses g++ as a linker when linking > > > c++ objects? > > > > This is a known problem: Object files as such don't have an indication > > that they come from a C++ file. It works when Aap also does the > > compilation, because an attribute is added to the object file then. > > > > A solution would be to store the attributes for the object file in the > > signature file AAPDIR/sign. That's not a small change though... > > Another solution may be to make aap remember what kind of files it > checked to determine if the objects in AAPDIR are up-to-date. Even when > hello.o exists, aap has to check before linking if it is consistent > with hello.cpp. Does aap know at that stage that it would use g++ > to update hello.o if it is old? If yes, maybe it can keep that > information and use g++ for linking. This is already possible, using "command block sections". This means the actions must explicitly split up the work in sections. One of the sections is always executed, adding the attribute to the object file should be done there. It's explained in file:///home/mool/aap/Aap/Exec/doc/user-depend.html about halfway. I didn't figure out what happens in your specific example. Perhaps the problem is that the ":rule" for .cpp to .o isn't used, but the compile action is invoked directly. For the ":rule" this is taken care of in the default.aap recipe. This is one area where Aap appears to be too complicated. I hope someone has a good idea how to simplify the use of actions and how they are defined. > > > (2) :toolsearch raises exception when it cannot find some tool. > > > > > > I am running my code on 2 different architectures - on the group linux > > > box and on university x86_64 high-performance linux cluster. The later > > > system has Intel c-compiler, which is not available on the group > > > machine. I created new tools file, intelcc.py, put it to the > > > ~/.aap/tools directory on cluster and used > > > > > > :toolsearch intelcc gcc > > > > > > in my main.aap. I thought this would work on both systems and aap > > > would choose gcc if intelcc was not defined. However aap raises > > > an exception and dies if it cannot find intelcc.py > > > > What is the exception? > > ImportError: No module named intelcc. > > I think aap should catch and ignore this exception and continue > searching for other tools. Exception should be raised when > :toolsearch cannot find any tool at all. The idea here is that the tool is present, but the exists() function will return False. Thus you would need to add the tool to all systems and make the exists() function work. Your patch ignores tools that don't exist. Although it is a nice solution in your situation, the problem is that typing mistakes in a tool name will go unnoticed. I don't like that, it's too easy to make a mistake here. > > > (3) when ~/.aap/tools contains some files, aap ignores default tools in > > > /usr/local/share/aap/tools > > > > > > doc/aap/ref-commands.html#cmd-usetool says that 3 directories are > > > searched for compiler tools, and they must contain __init__.py. In > > > fact only one directory is searched. Python uses for all imports the > > > first package directory that contains __init__.py, therefore aap can > > > find only tools in ~/.aap/tools, and the remaining directories are > > > ignored. I think the solution would be to add all tools directories > > > into sys.path (maybe only temporarily inside toolsearch or usetool > > > functions) or to use lower-level python import statements, so that all > > > tools directories could be searched. > > > > Aap already uses sys.path to do this. I can't say why it doesn't work > > for you... If you know a bit of python, look in the Commands.py file, > > the aap_toolsearch() function. > > The problem is that when python loads a module from package, it will > always use the first package directory that it finds in sys.path. > Therefore if ~/.aap/tools contains __init__.py and intelcc.py, aap > can only find intelcc, because python would always import from > ~/.aap/tools. A solution is to use the imp module which allows more > control over what is imported. This makes sense. Does this still work with Python 1.5? Although I don't worry about Python 1.5 compabitilty that much now. But it should be corrected in the documentation then. > Attached are patches for problems (2) and (3) with respect to the > latest cvs version. They seem to fix both issues. Thanks for making patches! I'll include the second one. -- hundred-and-one symptoms of being an internet addict: 223. You set up a web-cam as your home's security system. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://www.ICCF.nl /// |
From: Pavol J. <ju...@pa...> - 2005-11-28 16:50:24
|
On Mon, Nov 28, 2005 at 12:17:52PM +0100, Bram Moolenaar wrote: > > Pavol Juhas wrote: ... > > > > (1) aap is not using correct linker when linking c++ objects. ... > > > > Can this be fixed so that aap uses g++ as a linker when linking > > > > c++ objects? > > > > > > This is a known problem: Object files as such don't have an indication > > > that they come from a C++ file. It works when Aap also does the > > > compilation, because an attribute is added to the object file then. > > > > > > A solution would be to store the attributes for the object file in the > > > signature file AAPDIR/sign. That's not a small change though... > > > > Another solution may be to make aap remember what kind of files it > > checked to determine if the objects in AAPDIR are up-to-date. Even when > > hello.o exists, aap has to check before linking if it is consistent > > with hello.cpp. Does aap know at that stage that it would use g++ > > to update hello.o if it is old? If yes, maybe it can keep that > > information and use g++ for linking. > > This is already possible, using "command block sections". This means > the actions must explicitly split up the work in sections. One of the > sections is always executed, adding the attribute to the object file > should be done there. > > It's explained in file:///home/mool/aap/Aap/Exec/doc/user-depend.html > about halfway. A simpler way of telling aap to use g++ to link from hello.o is to add "LD=$CXXSHLINK" to main.app. > I didn't figure out what happens in your specific example. Perhaps the > problem is that the ":rule" for .cpp to .o isn't used, but the compile > action is invoked directly. For the ":rule" this is taken care of in > the default.aap recipe. > > This is one area where Aap appears to be too complicated. I hope > someone has a good idea how to simplify the use of actions and how they > are defined. BTW, I found another thing: ref-variables.html mentions USECXXLD variable, which should be set to "yes" when aap decides to use CXX for linking. However, when I use $USECXXLD in a recipe, aap complains about Unknown variable: "USECXXLD". I grepped for USECXXLD and it is nowhere in the aap sources. Is it an obsolete variable, or is there any code missing? > > > > (2) :toolsearch raises exception when it cannot find some tool. > > > > > > > > I am running my code on 2 different architectures - on the group linux > > > > box and on university x86_64 high-performance linux cluster. The later > > > > system has Intel c-compiler, which is not available on the group > > > > machine. I created new tools file, intelcc.py, put it to the > > > > ~/.aap/tools directory on cluster and used > > > > > > > > :toolsearch intelcc gcc > > > > > > > > in my main.aap. I thought this would work on both systems and aap > > > > would choose gcc if intelcc was not defined. However aap raises > > > > an exception and dies if it cannot find intelcc.py > > > > > > What is the exception? > > > > ImportError: No module named intelcc. > > > > I think aap should catch and ignore this exception and continue > > searching for other tools. Exception should be raised when > > :toolsearch cannot find any tool at all. > > The idea here is that the tool is present, but the exists() function > will return False. Thus you would need to add the tool to all systems > and make the exists() function work. > > Your patch ignores tools that don't exist. Although it is a nice > solution in your situation, the problem is that typing mistakes in a > tool name will go unnoticed. I don't like that, it's too easy to make a > mistake here. Well, it's a slight distinction - the original :toolsearch requires that a tool is defined and checks if it is installed, while the patched one checks if it is defined and installed. If user made a typo, he is asking to search for non-existing tool, so it won't be found - user just gets what he asked for. Perhaps there could be a :toolsearch option (allow_undefined_tools=yes or strict=no) for this behavior? In any case, I suggest to use the import code from my patch, otherwise there would be the same problem as with :usetool - the default tools will not be available as soon as user defines any custom tool in ~/.aap/tools. > > > > (3) when ~/.aap/tools contains some files, aap ignores default tools in > > > > /usr/local/share/aap/tools > > > > > > > > doc/aap/ref-commands.html#cmd-usetool says that 3 directories are > > > > searched for compiler tools, and they must contain __init__.py. In > > > > fact only one directory is searched. Python uses for all imports the > > > > first package directory that contains __init__.py, therefore aap can > > > > find only tools in ~/.aap/tools, and the remaining directories are > > > > ignored. I think the solution would be to add all tools directories > > > > into sys.path (maybe only temporarily inside toolsearch or usetool > > > > functions) or to use lower-level python import statements, so that all > > > > tools directories could be searched. > > > > > > Aap already uses sys.path to do this. I can't say why it doesn't work > > > for you... If you know a bit of python, look in the Commands.py file, > > > the aap_toolsearch() function. > > > > The problem is that when python loads a module from package, it will > > always use the first package directory that it finds in sys.path. > > Therefore if ~/.aap/tools contains __init__.py and intelcc.py, aap > > can only find intelcc, because python would always import from > > ~/.aap/tools. A solution is to use the imp module which allows more > > control over what is imported. > > This makes sense. Does this still work with Python 1.5? Although I > don't worry about Python 1.5 compabitilty that much now. But it should > be corrected in the documentation then. I checked the docs for Python 1.5 at http://www.python.org/doc/1.5/lib/node38.html and they say it has the imp module with the same functions I used in the patch. So it should be working, though I don't have python1.5 to test. Is there any other place where aap imports from tools? I guess the same fixes would apply there as well. Thanks for the aap. Pavol |
From: Bram M. <Br...@mo...> - 2005-11-28 20:53:17
|
Pavol Juhas wrote: > ... > > > > > (1) aap is not using correct linker when linking c++ objects. > ... > > > > > Can this be fixed so that aap uses g++ as a linker when linking > > > > > c++ objects? [...] > A simpler way of telling aap to use g++ to link from hello.o is > to add "LD=$CXXSHLINK" to main.app. Yes, but then all programs will use that linker. It would be nice if you can build both C and C++ programs automatically. > > I didn't figure out what happens in your specific example. Perhaps the > > problem is that the ":rule" for .cpp to .o isn't used, but the compile > > action is invoked directly. For the ":rule" this is taken care of in > > the default.aap recipe. > > > > This is one area where Aap appears to be too complicated. I hope > > someone has a good idea how to simplify the use of actions and how they > > are defined. > > BTW, I found another thing: ref-variables.html mentions USECXXLD > variable, which should be set to "yes" when aap decides to use CXX > for linking. However, when I use $USECXXLD in a recipe, aap > complains about Unknown variable: "USECXXLD". > I grepped for USECXXLD and it is nowhere in the aap sources. > Is it an obsolete variable, or is there any code missing? Right, this is old and should be removed. The cxx_build action does use $CXX for the default of $LD. This is not easy to explain... > Well, it's a slight distinction - the original :toolsearch requires > that a tool is defined and checks if it is installed, while the > patched one checks if it is defined and installed. If user made > a typo, he is asking to search for non-existing tool, so it won't be > found - user just gets what he asked for. Perhaps there could be > a :toolsearch option (allow_undefined_tools=yes or strict=no) for > this behavior? Hmm, another choice for the user. It's not really difficult to copy the tool to another system, is it? Consider the average use of a recipe: You copy it to another system with the files that are used and run it. The user should be warned if something is missing for the recipe to be executed properly. Note that the compiler searched for may be present, but when the Aap tool is missing it won't be found. That may result in an obscure problem in a larger application, that the wrong compiler is used might go unnoticed. > In any case, I suggest to use the import code from my patch, > otherwise there would be the same problem as with :usetool - the > default tools will not be available as soon as user defines any > custom tool in ~/.aap/tools. OK. Can you make a patch for that? > Is there any other place where aap imports from tools? I guess the > same fixes would apply there as well. Ehm, I don't know. It has been a while since I wrote this... -- hundred-and-one symptoms of being an internet addict: 235. You start naming your kids Pascal, COBOL, Algol and Fortran. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://www.ICCF.nl /// |
From: Pavol J. <ju...@pa...> - 2005-11-28 23:20:02
Attachments:
usetoolsearch.patch2
|
On Mon, Nov 28, 2005 at 09:53:45PM +0100, Bram Moolenaar wrote: > > Pavol Juhas wrote: > > > ... > > > > > > (1) aap is not using correct linker when linking c++ objects. > > ... > > > > > > Can this be fixed so that aap uses g++ as a linker when linking > > > > > > c++ objects? > > [...] > > > A simpler way of telling aap to use g++ to link from hello.o is > > to add "LD=$CXXSHLINK" to main.app. > > Yes, but then all programs will use that linker. It would be nice if > you can build both C and C++ programs automatically. For sure it would. Well, I found another mystery - for main.aap with LD=$CXX :program hello : hello.cpp the object-build works (aap; rm hello; aap), but if I add :usetool gcc to the begining, object-build stops working (clean build works). That happens with both the original and patched usetool. ... > > Well, it's a slight distinction - the original :toolsearch requires > > that a tool is defined and checks if it is installed, while the > > patched one checks if it is defined and installed. If user made > > a typo, he is asking to search for non-existing tool, so it won't be > > found - user just gets what he asked for. Perhaps there could be > > a :toolsearch option (allow_undefined_tools=yes or strict=no) for > > this behavior? > > Hmm, another choice for the user. It's not really difficult to copy the > tool to another system, is it? > > Consider the average use of a recipe: You copy it to another system with > the files that are used and run it. The user should be warned if > something is missing for the recipe to be executed properly. Note that > the compiler searched for may be present, but when the Aap tool is > missing it won't be found. That may result in an obscure problem in a > larger application, that the wrong compiler is used might go unnoticed. Ok, point taken. > > In any case, I suggest to use the import code from my patch, > > otherwise there would be the same problem as with :usetool - the > > default tools will not be available as soon as user defines any > > custom tool in ~/.aap/tools. > > OK. Can you make a patch for that? yep, it is attached. > > Is there any other place where aap imports from tools? I guess the > > same fixes would apply there as well. > > Ehm, I don't know. It has been a while since I wrote this... I only found import from tools in tools/dmd.py, so it probably does not work when custom tools are defined. dmd.py is doing many other things like writing to some files - I have no time now to figure out how to fix it and I don't use it anyway. Pavol |
From: Bram M. <Br...@mo...> - 2005-11-29 10:14:17
|
Pavol Juhas wrote: > > > ... > > > > > > > (1) aap is not using correct linker when linking c++ objects. > > > ... > > > > > > > Can this be fixed so that aap uses g++ as a linker when linking > > > > > > > c++ objects? > > > > [...] > > > > > A simpler way of telling aap to use g++ to link from hello.o is > > > to add "LD=$CXXSHLINK" to main.app. > > > > Yes, but then all programs will use that linker. It would be nice if > > you can build both C and C++ programs automatically. > > For sure it would. Well, I found another mystery - for main.aap with > LD=$CXX > :program hello : hello.cpp > the object-build works (aap; rm hello; aap), but if I add :usetool gcc > to the begining, object-build stops working (clean build works). > That happens with both the original and patched usetool. What is the problem then? If setting both $LD and ":usetool gcc", what would the writer of the recipe have intended? I would guess he wants to use gcc but with a different linker. > > > In any case, I suggest to use the import code from my patch, > > > otherwise there would be the same problem as with :usetool - the > > > default tools will not be available as soon as user defines any > > > custom tool in ~/.aap/tools. > > > > OK. Can you make a patch for that? > yep, it is attached. Thanks! I'll release a new version soon, so everybody can try it out. -- "The amigos also appear to be guilty of not citing the work of others who had gone before them. Even worse, they have a chapter about modeling time and space without making a single reference to Star Trek!" (Scott Ambler, reviewing the UML User Guide) /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://www.ICCF.nl /// |
From: Pavol J. <ju...@pa...> - 2005-11-30 16:42:46
Attachments:
hello.cpp
|
On Tue, Nov 29, 2005 at 11:15:10AM +0100, Bram Moolenaar wrote: > > Pavol Juhas wrote: > > > > > ... > > > > > > > > (1) aap is not using correct linker when linking c++ objects. > > > > ... > > > > > > > > Can this be fixed so that aap uses g++ as a linker when linking > > > > > > > > c++ objects? > > > > > > [...] > > > > > > > A simpler way of telling aap to use g++ to link from hello.o is > > > > to add "LD=$CXXSHLINK" to main.app. > > > > > > Yes, but then all programs will use that linker. It would be nice if > > > you can build both C and C++ programs automatically. > > > > For sure it would. Well, I found another mystery - for main.aap with > > LD=$CXX > > :program hello : hello.cpp > > the object-build works (aap; rm hello; aap), but if I add :usetool gcc > > to the begining, object-build stops working (clean build works). > > That happens with both the original and patched usetool. > > What is the problem then? Step by step reproduction - when main.aap contains :usetool gcc LD=$CXX :program hello : hello.cpp clean build works aap clean aap but object build does not (which is the problem) rm hello aap If you remove the :usetool line in main.aap, both builds would work. It seems :usetool is somehow breaking the object build procedure. Attached is the hello.cpp file if you'd like to test the problem. > > If setting both $LD and ":usetool gcc", what would the writer of the > recipe have intended? I would guess he wants to use gcc but with a > different linker. LD=$CXX means that user wants to link with whatever is the c++ compiler for the selected tool. It would be useful for a project where all the files are c++, but which may be compiled with different tools, e.g., gcc, icc, msvc. In that case the usetool line would be replaced with ":toolsearch gcc icc msvc". |
From: Bram M. <Br...@mo...> - 2005-11-30 19:58:40
|
Pavol Juhas wrote: > > What is the problem then? > > Step by step reproduction - when main.aap contains > > :usetool gcc > LD=$CXX > :program hello : hello.cpp > > clean build works > > aap clean > aap > > but object build does not (which is the problem) > > rm hello > aap > > If you remove the :usetool line in main.aap, both builds > would work. It seems :usetool is somehow breaking the object build > procedure. Attached is the hello.cpp file if you'd like to test the > problem. Thanks for the example. The problem is that the compile action in the gcc tool adds the "buildaction" attribute to the object file only when the source file is compiled. Unfortunately, at this place using sections is not supported, like it is in the rule. And the rule is not used for ":program". I can't think of an obvious solution. This would require some new mechanism. Either by supporting sections in actions (which is not logical) or adding optional "compile_nobuild" actions (which is clumsy). Perhaps we need a more drastic change to define actions in a tool in a better way. define_action() isn't very nice... > > If setting both $LD and ":usetool gcc", what would the writer of the > > recipe have intended? I would guess he wants to use gcc but with a > > different linker. > > LD=$CXX means that user wants to link with whatever is the > c++ compiler for the selected tool. It would be useful for > a project where all the files are c++, but which may be compiled > with different tools, e.g., gcc, icc, msvc. In that case the > usetool line would be replaced with ":toolsearch gcc icc msvc". The build_gxx action uses $GXX always. You are suggesting that it should use $LD if it is set. Wouldn't that have undesired/unexpected effects? I do think that the gcc tool should allow changing the linker used, but since it uses $GCC or $GXX that is not possible (the compile action would change too). Perhaps using $LD_GCC and/or $LD_GXX would help, then you can at least change the linker. Well, perhaps it is simpler to use $LD to overrule any linker used by the currently selected tool. -- hundred-and-one symptoms of being an internet addict: 269. You receive an e-mail from the wife of a deceased president, offering to send you twenty million dollar, and you are not even surprised. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://www.ICCF.nl /// |