Re: 3 aap suggestions

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:
> > >=20
> > > (1) aap is not using correct linker when linking c++ objects.
> > >=20
> ...
> > >=20
> > > Can this be fixed so that aap uses g++ as a linker when linking
> > > c++ objects?
> >=20
> > This is a known problem: Object files as such don't have an indicatio=
n
> > 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.
> >=20
> > A solution would be to store the attributes for the object file in th=
e
> > signature file AAPDIR/sign.  That's not a small change though...
>=20
> Another solution may be to make aap remember what kind of files it=20
> checked to determine if the objects in AAPDIR are up-to-date.  Even whe=
n=20
> hello.o exists, aap has to check before linking if it is consistent=20
> with hello.cpp.  Does aap know at that stage that it would use g++=20
> to update hello.o if it is old?  If yes, maybe it can keep that=20
> 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.
> > >=20
> > > I am running my code on 2 different architectures - on the group li=
nux
> > > box and on university x86_64 high-performance linux cluster.  The l=
ater
> > > 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
> > >=20
> > >     :toolsearch intelcc gcc
> > >=20
> > > 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
> >=20
> > What is the exception?
>=20
> ImportError: No module named intelcc.=20
>=20
> I think aap should catch and ignore this exception and continue=20
> searching for other tools.  Exception should be raised when=20
> :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 tool=
s in=20
> > >     /usr/local/share/aap/tools
> > >=20
> > > doc/aap/ref-commands.html#cmd-usetool  says that 3 directories are
> > > searched for compiler tools, and they must contain __init__.py.   I=
n
> > > fact only one directory is searched.  Python uses for all imports t=
he
> > > first package directory that contains __init__.py, therefore aap ca=
n
> > > find only tools in ~/.aap/tools, and the remaining directories are
> > > ignored.  I think the solution would be to add all tools directorie=
s
> > > 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.
> >=20
> > Aap already uses sys.path to do this.  I can't say why it doesn't wor=
k
> > for you...  If you know a bit of python, look in the Commands.py file=
,
> > the aap_toolsearch() function.
>=20
> The problem is that when python loads a module from package, it will=20
> always use the first package directory that it finds in sys.path. =20
> Therefore if ~/.aap/tools contains __init__.py and intelcc.py, aap=20
> can only find intelcc, because python would always import from=20
> ~/.aap/tools.  A solution is to use the imp module which allows more=20
> 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=20
> latest cvs version.  They seem to fix both issues.

Thanks for making patches!  I'll include the second one.

--=20
hundred-and-one symptoms of being an internet addict:
223. You set up a web-cam as your home's security system.

 /// Bram Moolenaar -- [email protected] -- 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         /=
//


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
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=3D7637&alloc_id=3D16865&op=3Dclick