Re: Automatic dependency checking problems
Bram Moolenaar <[email protected]> Fri, 07 May 2004 13:22:24 +0200
| Newsgroups | gmane.comp.tools.aap.user |
|---|---|
| Message-ID | <[email protected]> |
Thore Karlsen wrote:
> >> When I run AAP in cygwin, AAP defaults to using gcc. I have ":usetool
> >> MSVC" in my recipe. However, the gcccheck action has cc for $CC and gcc
> >> for $CXX. I assume this is because the value of these variables is
> >> substituted when the action is parsed, and not when it is actually
> >> invoked?
>
> >No, they are expanded when the action is invoked.
>
> Ah. I was getting confused, since this works as if the variable is
> expanded when the action is parsed:
>
> sourcefiles = Test1/main.cpp
> :program Test1 : $sourcefiles
>
> sourcefiles = Test2/main.cpp
> :program Test2 : $sourcefiles
>
> all : Test1 Test2
>
> Considering that Test1 and Test2 aren't really invoked until we get down
> to "all", which depends on them, why isn't Test1 built with
> Test2/main.cpp? That is the last value sourcefiles was set to.
>
> I guess what I'm asking is, when is the variable ultimately expanded?
There are two levels in a recipe: The commands at the toplevel and
dependencies are handled when they are encountered. But blocks of
commands of actions and dependencies are stored unmodified. They are
executed later, expanding variables happens then.
> >I think the problem simply is that the msvc tool doesn't set $CC or
> >$CXX. It only sets $MSVC.
> >
> >So, should a tool like msvc set $CC and $CXX, so that all places where
> >they are used will use the selected tools? I suppose so.
>
> I would say yes. I see the other tools do the same thing, and I'm not
> sure why. Perhaps there is a reason for it, but I don't see an
> explanation.
>
> The tools also use undocumented variables like LINKFLAGS to set flags.
> It seems to me that there should be standard variables for flags to the
> standard tools.
"it depends". If we have a standard format for $LINKFLAGS then all
tools can use it. But if you have a project where some files are
compiled with MSVC and some files with MingW, you might have link flags
that differ. Switching between the two tools should not result in the
variables becoming invalid.
The $CC and $CXX are generic: the C and C++ compiler. Thus when
selecting a tool I think these variables should be set. But variables
specific for one tool should have a name that's only used by that tool.
Does this make sense?
> >> This does appear to have done the trick. I had to trick AAP into
> >> believing that gcc wasn't present to get it to use aap_depend_c(),
> >> though.
>
> >Setting $CC and $CXX should help:
> >
> > CC = cl
> > CXX = cl
> >
> >May need to use _top.CC and _top.CXX when not in the main recipe.
>
> That worked, but it causes cl.exe to spit out an error message in
> gcccheck:
>
> cl : Command line warning D4002 : ignoring unknown option
> '/cygdrive/c/DOCUME~1/THOREK~1/LOCALS~1/Temp/tmpe_xfIU.c'
> cl : Command line error D2003 : missing source filename
>
> Isn't there a better way to check if gcc is used than to actually invoke
> it? Perhaps only run the test if $CC or $CXX is cc, gcc, or g++? Or even
> let the user explicitly select a method in the recipe.
The error message is disturbing. Skipping the check is probably the
only way to avoid it (stderr isn't very well supported on MS-Windows).
In the MSVC tool we should be able to tell gcccheck that it doesn't need
to try. Making this decision based on the command name is a bit too
magic for me. Adding a variable that tells gcccheck to skip the test
would be possible. Only problem then is what happens when you switch
tools. Well, gcccheck then gets confused anyway, since it's only run
once...
How about this:
- init HASGCC and HASGCCXX to empty
- When gcccheck is invoked it only does the test when HASGCC/HASGCCXX is
empty.
- A tool may change the value of HASGCC and HASGCCXX to skip the test
and force a result.
- You may set HASGCC and HASGCCXX to empty to have the gcccheck run the
test again.
A nice effect is that I can remove the hack in test 14 to set $CC to
"ignore_this" to use the internal dependency checker. That's an
indication we are on the right track.
Here is a patch to try out:
*** /home/mool/tmp/default.aap Tue Apr 13 20:56:32 2004
--- default.aap Fri May 7 11:20:00 2004
***************
*** 71,104 ****
# Use a dependency to avoid checking it more than once.
# Use an action to share the code between checking $CC and $CXX.
# TODO: handle the situation that $CC is not gcc but "gcc" does exist.
! HASGCC = no
! HASGCCXX = no
!
! gcccheck {virtual} :
! :do gcccheck dummy
!
! gcccheckxx {virtual} :
! :do gcccheck {check_cpp} dummy
:action gcccheck default
! MESSAGE = error # Don't echo the commands here
! @try:
! testfile = `tempfname()`.c
! outfile = `tempfname()`
! :eval "#ifdef __GNUC__\nyes;\n#endif\n" >! $testfile
! @if _no.get("check_cpp"):
! :sys $CXX -E $testfile > $outfile
! @else:
! :sys $CC -E $testfile > $outfile
! :cat $outfile | :assign tt
! @if string.find(tt, "yes") >= 0:
! @if _no.get("check_cpp"):
! _recipe.HASGCCXX = yes
! @else:
! _recipe.HASGCC = yes
! @except (StandardError, UserError), e:
! :log Warning: could not test C compiler for being GCC: `str(e)`
! :del {force}{quiet} $testfile $outfile
# Depending on the platform, check for available toolchains.
--- 71,105 ----
# Use a dependency to avoid checking it more than once.
# Use an action to share the code between checking $CC and $CXX.
# TODO: handle the situation that $CC is not gcc but "gcc" does exist.
! HASGCC =
! HASGCCXX =
:action gcccheck default
! @if _no.get("check_cpp"):
! val = $_recipe.HASGCCXX
! @else:
! val = $_recipe.HASGCC
! @if val == '':
! val = no # default result
! MESSAGE = error # Don't echo the commands here
! @try:
! testfile = `tempfname()`.c
! outfile = `tempfname()`
! :eval "#ifdef __GNUC__\nyes;\n#endif\n" >! $testfile
! @if _no.get("check_cpp"):
! :sys $CXX -E $testfile > $outfile
! @else:
! :sys $CC -E $testfile > $outfile
! :cat $outfile | :assign tt
! @if string.find(tt, "yes") >= 0:
! val = yes
! @except (StandardError, UserError), e:
! :log Warning: could not test C compiler for being GCC: `str(e)`
! :del {force}{quiet} $testfile $outfile
! @if _no.get("check_cpp"):
! _recipe.HASGCCXX = $val
! @else:
! _recipe.HASGCC = $val
# Depending on the platform, check for available toolchains.
***************
*** 126,137 ****
$($)?DEFINE $($)?INCLUDE}
c,cpp
@if filetype == 'c':
! :update gcccheck
usegcc = $HASGCC
cc = $CC
flags = $CFLAGS
@else:
! :update gcccheckxx
usegcc = $HASGCCXX
cc = $CXX
flags = $CXXFLAGS
--- 127,140 ----
$($)?DEFINE $($)?INCLUDE}
c,cpp
@if filetype == 'c':
! @if _no.HASGCC == '':
! :do gcccheck dummy
usegcc = $HASGCC
cc = $CC
flags = $CFLAGS
@else:
! @if _no.HASGCCXX == '':
! :do gcccheck {check_cpp} dummy
usegcc = $HASGCCXX
cc = $CXX
flags = $CXXFLAGS
--
hundred-and-one symptoms of being an internet addict:
153. You find yourself staring at your "inbox" waiting for new e-mail
to arrive.
/// Bram Moolenaar -- [email protected] -- 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 ///
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3