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

[John E. Malmberg]

On 3/10/2014 2:35 PM, h.becker wrote:
> On 03/08/2014 02:47 PM, John E. Malmberg wrote:
> > Since there will only be one build procedure and one resulting binary,
> > there would not be two templates.
> >
> > One of the main reasons for merging this fork back in is to get to one
> > make binary.
>
> It's not yet determined, whether there will be different binaries for
> the same platform (and same VMS version). Again, I prefer to keep it
> simple, whatever simple will be in this context.

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.

> > I am already expecting that a [.vms] directory will be needed to contain
> > at the minimum, the files needed for building the PCSI kit.
>
> Someone else needs to decide if these files should be in the GNU make
> repository. I didn't look, but I also didn't expect to see files to
> create a Debian or Red Hat package.

The GNU Gawk project had no problem accepting the files for creating a 
VMS PCSI kit.  The CURL project also had no problem accepting the same 
files.

> But what do I know. Also I don't
> know if the copyright for the wrapper code is OK, here.

The copyright is compatible with GPL 3 according to the GNU website.

If it needs to be assigned to the FSF as per a policy of the GNU make, 
then I need to go through the GNU copyright assignment process.
I have already gone through it with the GNU Awk project, so the FSF 
attorney already has the documentation needed.

> Anyway, appended is what I came up with. I don't expect this to be the
> final patch for this. So far it is only tested on Alpha/VMS 8.3.
>
> I'm not happy with hijacking main. What this code seems to do is
> replacing argv[0]. There seems to be no other change which affects the
> main entry. It seems to be enough to call a vms_mangle_argv0(&argv[0]);
> function, in main, just prior to when argv[0] is really used. This would
> be similar to calls like initialize_main() which is "Needed for OS/2".

The wrapper is generic and before the symbol modification added for 
make, is used to fix two problems.  The obvious one is the argv[0] 
issue.  The less obvious one the ability to fix the exit code if main 
did a return instead of calling exit() and the module was compiled with 
/define=_POSIX_EXIT.  The exit() issue does not apply to GNU Make.
It allows one quick fix for a common issue with out editing

What I can do is separate out the name mangling from the wrapper so that 
it can be called after main and be used in the case where I do not need 
the entire wrapper.

> Anyway, these changes all depend on what is configured in
> config.h[-vms[.template]]. (This also indicates that at the moment I
> expect different binaries depending on what a user "configures".) As
> default I used more or less the current behavior: no hihacking and no
> /tmp. It also seems that HAVE_VMS_MAIN_ENVP must be defined. If that's
> the case then there is no need to have it at all.

What does the configure?  Prepare_vms.com?  Manual edits should not be done.

The generic wrapper has to wrap around main routines that have the envp 
parameter and those that do not.  The majority of cases do not have the 
envp parameter present, that is why the default case does not have it 
defined.

> I did not test with DECC$POSIX_COMPLIANT_PATHNAMES or whatever affects
> the argv[0] passed by the CRTL. It seems worth to have some comments in
> these 300+ lines of code, which show some examples what is expected and
> what the result will be.

I will look at adding those examples down the road.  The module when 
built standalone contains test code that reports the before and after. 
I did try to put in comments of why it was doing each test.

> In my opinion, silently defining or overwriting a symbol shoulnd't be
> implemented. If the user wants/needs the argv[0] changed, she/he should
> define a symbol. That means, this needs to be documented, in the readme
> or in the config.h-vms.template.

Silent overwriting the symbol is wrong.  I put the original code in 
mainly to see if it would work.

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.

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

This behavior would be documented and would leave the original 
environment intact.

> On the other hand, moving the wrapper into an existing source file,
> which includes starlet.h, exhibited incompatible prototypes for system
> services, even without __NEW_STARLET defined. That is not really
> surprising, but there should be a better way than the hack I introduced.

I can disable my prototypes if something else includes <starlet.h>.  The 
starlet.h prototypes are missing the const qualifiers.

I think the wrapper or the argv replacement method should stay in its 
own module.  It is big enough to merit it.  If it is not pulled in by an 
#include, then it can be added to the makefiles.

> 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
> MAKE_FAILURE, so I used STS$K_ERROR.

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.

Regards,
-John