Hi,

I am trying to understand mk/tools.mk, so here are a few more questions:

Is there any version of Linux that does not come with GNU make installed?
(i.e. should _TOOLS_OPSYS_HAS_GNU.make contain Linux-*-*?)

Now to the real questions...

.for _tool_ in ${USE_GNU_TOOLS}
#
# What GNU tools did the package or user ask for, and does the base
# system already have it?
#
_TOOLS_NEED_GNU.${_tool_}=      YES
.  for _pattern_ in ${_TOOLS_OPSYS_HAS_GNU.${_tool_}}
_TOOLS_HAS_GNU.${_tool_}=       YES
.    if !empty(MACHINE_PLATFORM:M${_pattern_})
_TOOLS_NEED_GNU.${_tool_}=      NO
.    endif
.  endfor

Note that in the inner loop _tool_ is fixed. What sense does it make to
have
_TOOLS_HAS_GNU.${_tool_}=       YES
in the inner loop? 
What purpose does _TOOLS_HAS_GNU.${_tool_} serve at all?
To me this information is already contained in
_TOOLS_OPSYS_HAS_GNU.${_tool_}.
_TOOLS_HAS_GNU.${_tool_} does not seem to be used except for yacc.
Looking at the above code it seems that _TOOLS_OPSYS_HAS_GNU.${_tool_}
equals YES exactly if ${_tool_} is contained in USE_GNU_TOOLS.
 
  
Next, what sense does the test of _TOOLS_OPSYS_INCOMPAT.${_tool_} make?
(which is done for ${_tool_} in ${USE_GNU_TOOLS} only)  

_TOOLS_NEED_GNU.${_tool_} has already been set to YES, unless
MACHINE_PLATFORM is in _TOOLS_HAS_GNU.${_tool_}.
In the latter case, it should never be in _TOOLS_OPSYS_INCOMPAT.${_tool_}
though, shouldn't it?

So to me that section is completely useless.


Next, the line
#
# Are we using a GNUish system tool in place of the needed GNU tool?
#
is misleading. Note that we loop through _TOOLS here, not only
USE_GNU_TOOLS. So it should be called something like
# Are there any system tools that explicitly need to be symlinked?

What is also misleading is the use of "GNUish" in

# These platforms have GNUish versions of the tools available in the base
# system, which we already define as ${AWK}, ${SED}, etc. (refer to
# mk/platform/*.mk for the definitions), so no need to pull in the pkgsrc
# versions; we will use these instead.

above. As can be seen below in mk/tools.mk, _TOOLS_REPLACE_OPSYS.{_tool_}
only is of relevance if _TOOLS_NEED_GNU.${_tool_} is not set.
This makes sense, but then the comment re. _TOOLS_REPLACE_OPSYS should read
something like this:

# These platforms have usable versions of the tools available in the base
# system, which we already define as ${AWK}, ${SED}, etc. (refer to
# mk/platform/*.mk for the definitions), but they might need to be
# explicitly symlinked to be found.

I think here it becomes apparent that _TOOLS_OPSYS_INCOMPAT is not needed
at all (and in fact not used currently, as explained above).

So my understanding is that things are like this:

_TOOLS contains a list of all tools we potentially deal with
USE_GNU_TOOLS contains a user/package defined list of tools that have to be
GNU.
During execution of mk/tools.mk USE_GNU_TOOLS is potentially reduced if the
respective _IGNORE_GNU_TOOL.${_tool_} is set.

_TOOLS_OPSYS_HAS_GNU.${_tool_} indicates whether the system already comes
with a GNU version of _tool_. That one can either be in the system path or
referenced by the respective variable ($AWK, $SED, etc.)

Irrespectively of that, i.e. whether _tool_ is required in GNU form or not,
_TOOLS_REPLACE_OPSYS.${_tool_} indicates whether on the respective system
there is _tool_ defined as a variable and needs to be symlinked, since
otherwise it might not be found by the system (e.g. a different, undesired
instance with the standard name prior to it in the shell search path might
be used).

mk/tools.mk fills the following variables:

_TOOLS_HAS_GNU.${_tool_}
not needed nor used in my opinion, see above.


_TOOLS_NEED_GNU.${_tool_}
whether the GNU _tool_ from pkgsrc needs to be used


_TOOLS_REPLACE.${_tool_}

built from _TOOLS_REPLACE_OPSYS.${_tool_} with the same meening (just that
the tool/system "matrix" is inverted) 

_TOOLS_OVERRIDE.${_tool_}
whether to explicitly symlink something for ${_tool_}. (if so, "something"
is specified in the end by _TOOLS_PROGNAME.${_tool_}.)


What I honestly do not understand is the following (example for awk):

.if !empty(PKGPATH:Mlang/gawk)
_TOOLS_OVERRIDE.awk=    NO
MAKEFLAGS+=             _IGNORE_GNU_TOOL.awk=
.endif

If gawk is already installed, then do not override awk? Why? Does this
assume that packages installed are in the shell search path and moreover
are found with priority over the respective native system tools? This would
not necessarily be a valid assumption.


Moreover, it looks to me that mk/tools.mk assumes that $SED, $AWK, etc. are
plain paths to binaries, i.e. do not contain e.g. trailing options.
Correct? Would it be advisable to, just in case, strip off any trailing
options? Would the following do (assuming noone uses spaces in their file
system)?
_TOOLS_PROGNAME.awk=    ${AWK:S, .*$,,}


So far for my current understanding of mk/tools.mk.
Now the reason I looked into this is that I am considering whether it would
make sense to symlink other tools as well for systems (like mine :-)) where
the native equivalent in the shell path is not powerful enough, e.g. CP,
MV, RM, MKDIR, TEST, XARGS, TOUCH, CHOWN, CHGRP, TYPE, EGREP, FGREP.

On such systems one could, e.g. in /etc/mk.conf, add (as an example for cp)
_TOOLS_REPLACE_OPSYS.cp+={MACHINE_PLATFORM}.

All it would take to change in mk/tools.mk is to add the additional tools
to the _TOOLS= list and add respective handlers like

.if ${_TOOLS_REPLACE.cp} == "YES"
_TOOLS_OVERRIDE.cp=     YES
_TOOLS_PROGNAME.cp=     ${CP}
.endif

for the extra supported tools.

Georg
 
 

 
 

    

  




-- 
Georg Schwarz    http://home.pages.de/~schwarz/
 georg.schwarz@freenet.de     +49 178 8545053