On 03/07/2014 02:24 PM, John E. Malmberg wrote:
> On 3/6/2014 6:14 PM, h.becker wrote:
>> ...
>> For DCL it will be only one format.
>
> Not true. The decc$ features can be set by logical names, and a user
> may have set them for the various formats.
It as a user/administrator error to enable a decc$ feature with a
logical name other than /user prior to run the program which relies on
that feature (and is incorrectly coded not to use image initialization
code).
> If a C program can be broken by an incorrect decc$ feature name, it
> should protect itself with a lib$initialize section.
I disagree. The decc$ feature design is broken and should be fixed,
maybe with a feature logical :-). Any program which relies on a decc$
feature should set it with image initialization code (or any other
appropriate interface provided by the crtl). But that is another
discussion and doesn't seem to belong here.
> How about this, I append the process ID string to the symbol to make it
> unique, and then use an at_exit() call to delete it.
I suggest to have it settable in config.h-vms[.template].
> This program wraps around the main() module, so either must be included
> into main either implicitly, or with a /first_include feature.
As far as I see and coded it: no. The only reason to include code into
other code is when the included code has to access static
variables/functions of the "includer". As far as I see, that's not the case.
>>> If someone has defined /TMP to other than SYS$SCRATCH: then they will
>>> probably be suprised if a GNU utility is not honoring it and still using
>>> SYS$SCRATCH:
>>
>> For DCL, I don't think so.
>
> What ever is done, it needs to be documented in the readme.vms and
> probably the gnu make manual as a VMS feature. As clear
>
> To have it different under GNV will require a global variable to use as
> a flag to be set if getenv("SHELL") returns a value, as I do think we
> want to call gentenv("SHELL") every place GNV needs alternative behavior.
Again, I would want to make it settable in config.h-vms[.template].
Maybe it is necessary to create a config.h-gnv[.template], but I don't
know, yet. And yes, it needs to be documented.
On the other hand, P_temdir is defined in the recent version of stdio.h
as "SYS$SCRATCH:", so I'm not sure whether your change to use /tmp will
work. And it seems like the RTL engineers or whoever wrote stdio.h think
this is what developers/users expect.
>> I prefer to have all vms specific code in the existing vms sources,
>> vmsfunctions.c may be the one for the new code.
>
> I would prefer multiple modules, so that they can be re-used between
> other projects. A vmsfunctions.c could #include these modules.
The reason I want to use existing ones is simple: I don't want to add so
many vms specific source files. But if there will be a config.h-gnv,
then there may be [a] gnv specific source[s] as well. Anyway, this is
still GNU make and not VMS make :-)
As already said, I try to move the code and will post that as a
suggestion this weekend.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
