Re: Gnu Make operating conditions

[Paul Smith]

On Thu, 2014-06-05 at 18:45 +0530, chandrababu nallani wrote:

It's important to understand that GNU make is a utility which exists to
run other tools, such as compilers, linkers, or whatever other programs
your makefile tells it to.

As such we can answer the following questions for the GNU make tool
itself, but we cannot answer them in general because your particular
makefile or the tools that your makefile tells make to run may have
different behaviors in these situations.

Also, it's possible to build GNU make in different ways, such as part of
the Cygwin environment, with MinGW, as a native tool with MSVC, etc. and
some of these answers may depend on how you built it.

>      1. Assume the Gnu Make tool depends on the environment variable
>         <X>, which is set on installation of the tool. The user does
>         not know this and has accidently redefined <X> to another
>         value.

GNU make itself does not set any environment variables when it's
installed and doesn't rely on any environment variables being set in
order to run properly.

>      1. Assume the Gnu Make depends on some dlls from the operating
>         system or other extensions, e.g. service packs or .NET
>         packages. What happens if these dll files are accidently
>         replaced by other versions. Does the tool recognize this, e.g.
>         by checking if the correct versions of expected dlls are
>         present?

Someone familiar with Windows GNU make will have to reply.  I'm fairly
confident you can build GNU make as a static tool (so it doesn't use any
DLLs).  If it does use DLLs then it uses only the most fundamental,
basic system DLLs which would not change behavior when upgraded.

However, as far as I know there is no facility in GNU make for checking
DLL versions.

>      1. Assume that the Gnu Make depends on some entries to the
>         windows registry, which are set on installation of the tool.
>         The user has installed other tools, e.g. other versions of the
>         same tool, or done something else, so that these registry
>         values have changed to other values.

GNU make itself does not add any entries to the Windows registry.

>      1. Assume that somebody has accidently deleted some files from
>         the Gnu Make installation directory, or the installation has
>         not completed.

There are no other files in the GNU make installation, except the GNU
make program.

>      1. Assume that two instances of the Gnu Make are executed on the
>         same windows session at the same time. Are both instances
>         running completely independently? Is it possible that both
>         instances write/read data, e.g. temporary files, to/from the
>         same resource?

Both instances of GNU make would be completely independent (unless your
makefiles had overlapping behaviors).

>      1. Assume the Gnu Make is executed in a situation where the CPU
>         is very busy with executing other programs. Hence, the
>         execution of the tool gets interrupted extremely often. Can
>         this situation cause deviations in the tool’s outputs?

If you use the parallel build feature of GNU make then changes in the
length of time it takes compilers or other commands to finish can change
the order in which subsequent commands may be invoked, if they have no
dependencies on each other.  If the makefile is written correctly, the
output will always be the same regardless of this order.

If you don't use parallel builds then the order in which GNU make
invokes commands will always be the same regardless of how busy the CPU
is.

>      1. Assume the Gnu Make is executed in a situation where the
>         available RAM becomes lower than specified in the minimal
>         system requirements. Can this situation cause deviations in
>         the tool’s outputs?

If GNU make attempts to allocate memory and fails, it will exit
immediately with a failure.