Re: 3 aap suggestions

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click