Gnu Make operating conditions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Gnu Make operating conditions

chandrababu nallani

Hi ,

I am using Gnu Make 3.80 on windows. I have few Gnu Make operating conditions in some situations under Windows listed in the below. Could you please explain how Gnu Make behaves under these operating conditions? I hope this may take time. Could you please give a quick explanation in less words if possible.
 
The listed operating conditions are,
 
  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.
  2. 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?
  3. 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.
  4. Assume that somebody has accidently deleted some files from the Gnu Make installation directory, or the installation has not completed.
  5. 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?
  6. 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?
  7. 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?
 

 

Thank you for your time.

Thanks,

Chandrababu


_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32
Reply | Threaded
Open this post in threaded view
|

Re: Gnu Make operating conditions

Paul Smith-20
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32
Reply | Threaded
Open this post in threaded view
|

Re: Gnu Make operating conditions

Eli Zaretskii
In reply to this post by chandrababu nallani
> Date: Thu, 5 Jun 2014 18:45:29 +0530
> From: chandrababu nallani <[hidden email]>
>
> I am using Gnu Make 3.80 on windows.

That is an old and buggy version of Make.  It has a couple of
Windows-specific bugs fixed in version 3.81 and later.  So I suggest
to use Make 3.82.  (The last version of Make is 4.0, but it is not yet
as stable as 3.82.)

>    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 does not need any environment variables for its work.

>    2. 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?

GNU Make doesn't depend on any DLLs that can be removed from a Windows
system without rendering that system completely unusable.  There are
no issues with versions of those DLLs, because the same DLLs are used
by the OS itself all the time.

>    3. 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 does not access or need any registry entries.

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

GNU Make installation is a single executable (and a couple of
documentation files), so this can hardly happen.

>    5. 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?

Temporary files are written to the temporary directory, but the names
of those files are computed dynamically so as not to conflict with
existing files.

>    6. 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?

No.  GNU Make is a single-threaded program.

>    7. 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 there's not enough virtual memory for Make to create its data
structures, you will get a fatal error message and Make will abort.
But you need to have extremely memory-tight conditions and/or a very
large build, for this to happen.


_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32
Reply | Threaded
Open this post in threaded view
|

Re: Gnu Make operating conditions

Eli Zaretskii
In reply to this post by Paul Smith-20
> From: Paul Smith <[hidden email]>
> Date: Thu, 05 Jun 2014 11:33:05 -0400
> Cc: [hidden email]
>
> On Thu, 2014-06-05 at 18:45 +0530, chandrababu nallani wrote:
>
> >      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).

Not on Windows, not unless you use some proprietary compiler that
provides a static libc.  Otherwise, you must link against the shared
library version of the C runtime.

> If it does use DLLs then it uses only the most fundamental,
> basic system DLLs which would not change behavior when upgraded.

Indeed.

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

No such facility and no need for it.

_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32
Reply | Threaded
Open this post in threaded view
|

Re: Gnu Make operating conditions

Paul Smith-20
On Fri, 2014-06-06 at 21:11 +0530, chandrababu nallani wrote:
> Hi Eli and Paul,

Please always send all your questions to the mailing list, not to
individual developers specifically.

> 1. Assume a system has low disk space. How GNU Make behaves if I run
> in this situation?

GNU make itself does not write any files to the disk, so it won't be
aware of low disk space situations.

> 2.Assume residual files are left after a GNU Make is uninstalled or
> updated. And again I installed another version of GNU Make without
> cleaning the files. Will new version works properly or not?

As mentioned before, the installation of GNU make consists of one single
file, the .exe file.  So there cannot be any "residual files" left.



_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32