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. _______________________________________________ Make-w32 mailing list [email protected] https://lists.gnu.org/mailman/listinfo/make-w32
