GNV and CRTL

[Martin Vorlaender]

Ouch!

Of course I didn't think of stepping into the stat call...

Time to update the GPB'ed portions of gpatch, I guess.

Thanks a lot!

Over and out...

[H.Becker]

>>> I'm in the process of building the GNV environmet from scratch, so no GNV utilities, please (except where the build process calls them).

Is this really "from scratch"? It seems good enough to build GNV from the known source tree and then use its tools to create a branch.

On the other hand, did you try the VMS tools for that: diff/slp and edit/sumslp?

[Martin Vorlaender]

Hartmut,

no, this isn't from scratch in the sense that I'm not starting with the SF sources.

The "Building GNV" page at http://gnv.sourceforge.net/building.html starts from the source files installed with the binary kit, i.e. a working GNV environment is assumed to build GNV from source.

As I find this to be a bit absurd, I tried to *really* build from the sources, i.e. download the source files from SourceForge onto a VMS system equipped with just the compilers (NB: it doesn't say anywhere you need BLISS installed [to build vitpu]). That's what I meant when writing "from scratch".

I'm comfortable with GNU patch usually, and haven't ever used SUMSLP, so I never thought of using that.

cu,
Martin

[H.Becker]

To me Posix on VMS was the unwanted child, GNV seems to be wanted somehow, but neglected.

There are cvs commands shown on sourceforge, which do not work: That means you can't take a snapshot or check out any module via cvs, except you are registered/permitted. You just can browse and view (download) each single file. That may make sense when there is no cvs for VMS. Is there?

But there is a GNV tarball, gnv.tar.gz, which contains both source trees. Why someone would want both at the same time is unknown to me. This file shows under "browse code". Then you need just a recent tar utility on VMS.

So you can get a full source tree without installing the binaries. Whether this is the same tree as the one which comes with the binaries is unknown to me.

I didn't see any readme or so, but I would just kick off a "@[.build]build all". (I haven't tried it, I currently don't have access to a system with enough resouces andd a BLISS compiler).

[Martin Vorlaender]

>>>
There are cvs commands shown on sourceforge, which do not work: That means you can't take a snapshot or check out any module via cvs, except you are registered/permitted.
<<<

I used TortoiseCVS for Windows to checkout the source tree (which is integrated into Exploder) but you made me curious, so I tried the commands from http://sourceforge.net/projects/gnv/develop . The first one asks for a password, but it's okay to just press RETURN there. For the second one, you have to look up via "browse code" that the module name is "gnv213". Then it checks out the source tree okay.

>>>
I didn't see any readme or so, but I would just kick off a "@[.build]build all".
<<<

The "doc" folder has a "Read Me First" in TXT, PS, PDF, and HTML. It's for version 1.6 (July 2004), though. And the PDF is broken. But that folder at least has current release notes. And there's the "Building GNV" web page I mentioned.

You'll need multiple rounds of build.com, as several build files use GNV commands (e.g. bash, make, which, dcl, patch) - which of course is not a problem if you're starting with GNV already installed...

And, of course, neither the kitting commands nor GNV$STARTUP.COM is included.

cu,
Martin

[Martin Vorlaender]

Just FYI:

Conditionalizing most of vmsutil.c:do_tovmsspec() with "#if __CRTL_VER < 70000000 || defined (LINK_TARGET_PRE7)" yields:

- gpatch can now cope with dots in directory names, i.e. the stat call isn't failing any more

- gpatch doesn't understand VMS filename syntax on the command line any more (e.g. for the -i filename).

Yes, it would have been better to get a current do_tovmsspec() from the perl 5.12.2 sources, but laziness prevails (for now, at least).

cu,
Martin