Re: [PATCH] Win32 native support II

[Ruurd Reitsma]

"Andre Poenitz" <[EMAIL PROTECTED]> wrote
> I don't like the idea of putting #ifdef _WIN32 etc everywhere in the
> code. Can't this be put into some helper functions that are put
> somewhere under src/support?
Well, it could. However, most _WIN32 #ifdefs outside of support are one-time
issues that would need very specific helper functions. Anyway, the __EMX__
stuff is also still there.
>
> --- src/graphics/GraphicsParams.h 2002/07/21 15:51:07 1.14
> +++ src/graphics/GraphicsParams.h 2002/07/26 10:11:41
> @@ -19,6 +19,9 @@
> #include "GraphicsTypes.h"
> #include "LString.h"
>
> +#ifndef uint
> +typedef unsigned int uint;
> +#endif
>
>
> Why is that needed?

GraphicsImageXPM.C needs it. It should move elsewhere, I agree.

> Index: src/DepTable.C
>
> +#ifdef _WIN32
> +#include "times.h"
> +#endif
> +
> Shouldn't that be done by configure?
> Why "..." and not <...>?

That one can go...

> RCS file: /cvs/lyx/lyx-devel/src/buffer.C,v
> - if (::utime(s.c_str(), ×)) {
> + if (utime(s.c_str(), ×)) {
> lyxerr << "utime error." << endl;
> Why?

Oops..

> diff -u -r1.117 lyx_main.C
> --- src/lyx_main.C 2002/07/22 18:56:03 1.117
> +++ src/lyx_main.C 2002/07/26 10:11:13
> @@ -17,7 +17,6 @@
>
> #include "support/filetools.h"
> #include "support/lyxlib.h"
> -#include "support/os.h"
> #include "support/FileInfo.h"
> #include "support/path.h"
> #include "debug.h"
> @@ -42,6 +41,8 @@
> #include 
> #include 
>
> +#include "support/os.h"
> +
> using std::vector;
> using std::endl;
>
>
>
> Why?

Os.h throws in some POSIX signal defs if it detects _SIGNAL_H_

>
> -class latexkeys;
> +struct latexkeys;
>
>
> I'd rather change the struct into a class than changing all the
> forawrd declarations.

OK!

> Index: src/support/fmt.C
> +#ifdef _WIN32
> +#define snprintf(m,n,o,p) _snprintf(m,n,o,p)
> +#define vsnprintf(m,n,o,p) _vsnprintf(m,n,o,p)
> +#endif
> +
> #include "LString.h"
>
>
> Why is that #define stuff not in support/snprintf.h?
BecauseI dunno.
> Index: src/support/kill.C
>
> #include 
> #include 
> +#include "os.h"
>
> int lyx::kill(int pid, int sig)
> {
>
> What needs that os.h header?
>

kill();

> --- src/support/os.h 2002/03/21 17:06:35 1.6
> +++ src/support/os.h 2002/07/26 10:11:58
> @@ -1,5 +1,9 @@
> // os.h copyright "Ruurd A. Reitsma" <[EMAIL PROTECTED]>
>
> +#ifdef _WIN32
> +#include "os_win32.h"
> +#endif //_WIN32
> +
> #ifndef OS_H
> #define OS_H
>
> Why is comes that include before the include guard?
>
Again, no reason.
Wellit seems you're paying more attention then I did I've updated
the diff.
Ruurd

Re: [PATCH] Win32 native support II

[Andre Poenitz]

On Fri, Jul 26, 2002 at 02:28:34PM +0200, Ruurd Reitsma wrote:
> Well, it could. However, most _WIN32 #ifdefs outside of support are one-time
> issues that would need very specific helper functions. Anyway, the __EMX__
> stuff is also still there.

So that should probably be moved, too.

> > +++ src/graphics/GraphicsParams.h 2002/07/26 10:11:41
> > @@ -19,6 +19,9 @@
> > #include "GraphicsTypes.h"
> > #include "LString.h"
> >
> > +#ifndef uint
> > +typedef unsigned int uint;
> > +#endif
> >
> >
> > Why is that needed?
> 
> GraphicsImageXPM.C needs it. It should move elsewhere, I agree.

Its not really needed, line 562 there should be something like

  return static_cast(i);

> > #include 
> > #include 
> >
> > +#include "support/os.h"
> > +
> > using std::vector;
> > using std::endl;
> >
> >
> >
> > Why?
> 
> Os.h throws in some POSIX signal defs if it detects _SIGNAL_H_

Headers should be self-contained, shouldn't they? So I thnik the proper way
to do it is to include  in support/os.h.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: [PATCH] Win32 native support II

[Ruurd Reitsma]

"Kuba Ober" <[EMAIL PROTECTED]> wrote

> Do you have your VS updated with the latest service pack? I imagine some
> things that you patch might be VC++ quirks that might have got fixed in
SP's.

I imagine i would have never gotten this far without the service packs...and
even then.
I'm not using the compiler anyway, just the IDE. The intel compiler 6.0
compiler is quite complaint.

Ruurd