[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vms argv[0] and exit status fixes.

From: h.becker
Subject: Re: vms argv[0] and exit status fixes.
Date: Tue, 11 Mar 2014 21:09:57 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130519 Icedove/17.0.5

On 03/11/2014 04:09 AM, John E. Malmberg wrote:
> Gnu make is already checking to see if a shell is present for other
> platforms, and is already tracking the information needed for VMS to do
> the same.

And at that point you can make sure that VMS file versions can be used
as specified on the VMS command line, like: "$ make -f makefile;-1" ?

> I also want the program name to accurately reflect the image name, so
> that my deb_make.exe shows up differently than make.exe with the --help
> option.

As far as I understand, then the deb_make.exe (or one with ;version)
shows up in argv[0] as deb_make.

There is argv[0], there is program and there is MAKE[_COMMAND]. It seems
that program is set to something like basename of argv[0] and
MAKE_[COMMAND] is set to argv[0].

program is used for output as in "Usage:", error messages etc., $(MAKE)
can be used to run the same make from a Makefile.

For VMS with DCL, my suggestion was to leave argv[0] as provided by the
CRTL, to set program to "make", and MAKE[_COMMAND] to "mcr "+argv[0].
the latter avoids the need of a symbol for the use of $(MAKE).

I admit, whether "make" or the image name should be used for program is
debatable. If argv[0] is changed and no longer holds the full file spec,
and program is set to the image name, it would be much simpler to just
to prefix "mcr " to the original argv[0] and write that into
MAKE[_COMMAND] instead of the mangled argv[0], again, avoiding the DCL

> So my solution is save any local symbol that may exist, create the
> symbol, and then restore the state of the local symbol afterward.

Any matching symbol, right? But with the restore in atexit() and all
ctrl+c, ctrl+y handlers. Looks like quite a bit of code. Not that I
really suggest this, but prepending or creating a user mode DCL$PATH
logical with the path to the image should do. Seems much easier.

>> On MAKE_TROUBLE, I agree, as this is a failure status on Unix - it will
>> stop make as well - this should be in the same failure range as
> A Warning status should also stop the build, unless there is a bug there
> also.
> A warning status also allows a DCL script to take a different action on
> the severity, and seems more in the spirit of how GNU make is documented
> to behave.

Maybe I misunderstood the comment in the last mail. A Unix failure
status looks like a VMS error status. Where is the spirit of GNU make
regarding MAKE_TROUBLE?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]