Re: [Gcl-devel] Re: open-axiom builds on mingw32

[Gabriel Dos Reis]

Camm Maguire <address@hidden> writes:

| Greetings!
| 
| Gabriel Dos Reis <address@hidden> writes:
| 
| > I believe you need something like:
| >
| >     LARGE_INTEGER ticks;
| >     if (QueryPerformanceFrequency(&ticks)) {
| >        /* high resolution available.  /
| >        const double micros = 1.0e6/ticks.QuadPart;
| >        LARGE_INTEGER snapshot;
| >        QueryPerformanceCounter(&snapshot);
| >        return make_longfloat(snapshot.QuadPart * micros);
| >     else {
| >        /* high resolution not available.  Use something else. */
| >     }
| 
| Thanks.  Separately, the oddest cvs phenomenon -- gcl_cmpmain.lsp is
| 30550 bytes, but win32 cvs adds \r in front of each \n to give a
| larger file which won't compile (as it corrupts a string therein.)
| Yet cvs diff -u shows nothing on the bad and on the correct file.  

Ah, now that you gave me more context, I can tell you something more
sensible than what I said earlier :-)

On Windows, I use TortoiseCVS -- the graphic interface to cvs.
It lets you select 'UNIX line endings' when checking out, look in the 
"Options" tab.  I don't think it is retroactive, so I suspect you would
have to redo a complete checkout with that box checked.  I do not know
what the correspondong command line option is.

| I'm hoping this is a local cvs bug/problem, and not something I need
| to address.  But on the box in question, I have to retrieve the
| correct file with wget.

Yes, it is complete something local to CVS -- or any program writing 
"text files" on windows.  So, if you put out a tarbal and download it 
with ftg or wget in binary mode, you don't see the problem.

-- Gaby