Re: The latest patches break cygwin again
On Wed, Feb 02, 2005 at 09:55:53AM +, Angus Leeming wrote: to constuct these paths because, as we've just found out, Boost.Filesystem expects a particular OS to use either Windows or Posix-style paths and Cygwin can use BOTH. ... even within the same file name. I.e. 'C:Programs\LyX/lib' just works. [Could well be this works in the Windows system calls without Cygwin, but not from the 'shell'] Andre'
Re: The latest patches break cygwin again
On Wed, Feb 02, 2005 at 09:55:53AM +, Angus Leeming wrote: > to constuct these paths because, as we've just found out, Boost.Filesystem > expects a particular OS to use either Windows or Posix-style paths and > Cygwin can use BOTH. ... even within the same file name. I.e. 'C:Programs\LyX/lib' just works. [Could well be this works in the Windows system calls without Cygwin, but not from the 'shell'] Andre'
Re: The latest patches break cygwin again
L #define BOOST_POSIX 1 | Yes, this works. Ok. Then we have to decide on the best way to handle this. If we just make BOOST_POSIX be set for cygwin, then it works for you. But for the next guy using cygwin it will break. No, I don't think so. All our file names currently go through internal_path which sort-of-posixifies them. I've no idea why things appear to be working on a true Windows platform, but I think you've just been lucky. Seems to me that this is an example of coding practice that we should try and avaoid in future... So are there any kindo of configure tests we can use to discover the setting of win/posix kind of setup on cygwin? Cygwin can understand both. Boost.Filesystem is poorly designed in this regard. It's been noted before on the boost lists. -- Angus
Re: The latest patches break cygwin again
Angus Leeming [EMAIL PROTECTED] writes: | L #define BOOST_POSIX 1 | Yes, this works. Ok. Then we have to decide on the best way to handle this. If we just make BOOST_POSIX be set for cygwin, then it works for you. But for the next guy using cygwin it will break. | No, I don't think so. All our file names currently go through | internal_path which sort-of-posixifies them. I've no idea why things | appear to be working on a true Windows platform, but I think you've just | been lucky. Ok, then we are back to scratch. What you are saying is that using filesystem calls from windows.h is perfectly ok when writing appications for cygwin? -- Lgb
Re: The latest patches break cygwin again
Lars Gullik Bjønnes wrote: | L #define BOOST_POSIX 1 | Yes, this works. Ok. Then we have to decide on the best way to handle this. If we just make BOOST_POSIX be set for cygwin, then it works for you. But for the next guy using cygwin it will break. | No, I don't think so. All our file names currently go through | internal_path which sort-of-posixifies them. I've no idea why things | appear to be working on a true Windows platform, but I think you've | just been lucky. Ok, then we are back to scratch. What you are saying is that using filesystem calls from windows.h is perfectly ok when writing appications for cygwin? I think that we two need to sit down with beers, because all this long-distance typing just leads to mutual confusion. I'm not trying to have a go. I'm just trying to help see through the mess. At the moment, we have a bit of this and a bit of that. We have the old way, in which all file names are sort-of-posixified by os::internal_path before the rest of LyX sees them. Similarly, we sort-of-go-native when we pass these names through os::external_path on the way back to the outside world. We have the new, Boost.Filesystem way which handles all operations on these file names. You've got lucky because you're effectively constructing these fs::paths using generic Boost.Filesystem path syntax. Ie, you're always passing sort-of-posixified file names to the fs::path constructor, irrespective of the OS. I guess that the problems are arising because of this half one way, half the other. Unfortunately, we can't get rid of os::internal_path and use the obvious and explicit fs::path(name, fs::native); to constuct these paths because, as we've just found out, Boost.Filesystem expects a particular OS to use either Windows or Posix-style paths and Cygwin can use BOTH. Boost.Filesystem cannot cope with that. That's my yake on the situation. Does it make sense to you too? -- Angus
Re: The latest patches break cygwin again
L>>> #define BOOST_POSIX 1 >> > | Yes, this works. > > Ok. > > Then we have to decide on the best way to handle this. > > If we just make BOOST_POSIX be set for cygwin, then it works for you. > But for the next guy using cygwin it will break. No, I don't think so. All our file names currently go through "internal_path" which sort-of-posixifies them. I've no idea why things appear to be working on a true Windows platform, but I think you've just been lucky. Seems to me that this is an example of coding practice that we should try and avaoid in future... > So are there any kindo of configure tests we can use to discover the > setting of win/posix kind of setup on cygwin? Cygwin can understand both. Boost.Filesystem is poorly designed in this regard. It's been noted before on the boost lists. -- Angus
Re: The latest patches break cygwin again
Angus Leeming <[EMAIL PROTECTED]> writes: | L>>> #define BOOST_POSIX 1 >>> >> | Yes, this works. >> >> Ok. >> >> Then we have to decide on the best way to handle this. >> >> If we just make BOOST_POSIX be set for cygwin, then it works for you. >> But for the next guy using cygwin it will break. > | No, I don't think so. All our file names currently go through | "internal_path" which sort-of-posixifies them. I've no idea why things | appear to be working on a true Windows platform, but I think you've just | been lucky. Ok, then we are back to scratch. What you are saying is that using filesystem calls from windows.h is perfectly ok when writing appications for cygwin? -- Lgb
Re: The latest patches break cygwin again
Lars Gullik Bjønnes wrote: > | L>>> #define BOOST_POSIX 1 >>> | Yes, this works. >>> >>> Ok. >>> >>> Then we have to decide on the best way to handle this. >>> >>> If we just make BOOST_POSIX be set for cygwin, then it works for you. >>> But for the next guy using cygwin it will break. >> > | No, I don't think so. All our file names currently go through > | "internal_path" which sort-of-posixifies them. I've no idea why things > | appear to be working on a true Windows platform, but I think you've > | just been lucky. > > Ok, then we are back to scratch. > > What you are saying is that using filesystem calls from windows.h is > perfectly ok when writing appications for cygwin? I think that we two need to sit down with beers, because all this long-distance typing just leads to mutual confusion. I'm not trying to have a go. I'm just trying to help see through the mess. At the moment, we have "a bit of this and a bit of that". We have the "old" way, in which all file names are "sort-of-posixified" by os::internal_path before the rest of LyX sees them. Similarly, we "sort-of-go-native" when we pass these names through os::external_path on the way back to the outside world. We have the "new", Boost.Filesystem way which handles all operations on these file names. You've got lucky because you're effectively constructing these fs::paths using "generic Boost.Filesystem path syntax". Ie, you're always passing "sort-of-posixified" file names to the fs::path constructor, irrespective of the OS. I guess that the problems are arising because of this "half one way, half the other". Unfortunately, we can't get rid of os::internal_path and use the obvious and explicit fs::path(name, fs::native); to constuct these paths because, as we've just found out, Boost.Filesystem expects a particular OS to use either Windows or Posix-style paths and Cygwin can use BOTH. Boost.Filesystem cannot cope with that. That's my yake on the situation. Does it make sense to you too? -- Angus
Re: The latest patches break cygwin again
Kayvan A. Sylvan [EMAIL PROTECTED] writes: | I just tried compiling latest CVS again. Here is what happens: | g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src | -I../../../lyx/src/support/.. -I../../../lyx/boost -I/usr/local/include | -W -Wall -I/usr/X11R6/include -O2 -fno-exceptions -mms-bitfields | -MT fs_extras.lo -MD -MP -MF .deps/fs_extras.Tpo -c | ../../../lyx/src/support/fs_extras.C -o fs_extras.o | ../../../lyx/src/support/fs_extras.C: In function `bool |boost::filesystem::is_readable(const boost::filesystem::path)': | ../../../lyx/src/support/fs_extras.C:36: error: `DWORD' undeclared (first use Does it help if you add a #include windows.h to this file (fs_extras.C) -- Lgb
Re: The latest patches break cygwin again
On Tue, Feb 01, 2005 at 10:59:47AM +0100, Lars Gullik Bjønnes wrote: Kayvan A. Sylvan [EMAIL PROTECTED] writes: | I just tried compiling latest CVS again. Here is what happens: | g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src | -I../../../lyx/src/support/.. -I../../../lyx/boost -I/usr/local/include | -W -Wall -I/usr/X11R6/include -O2 -fno-exceptions -mms-bitfields | -MT fs_extras.lo -MD -MP -MF .deps/fs_extras.Tpo -c | ../../../lyx/src/support/fs_extras.C -o fs_extras.o | ../../../lyx/src/support/fs_extras.C: In function `bool |boost::filesystem::is_readable(const boost::filesystem::path)': | ../../../lyx/src/support/fs_extras.C:36: error: `DWORD' undeclared (first use Does it help if you add a #include windows.h to this file (fs_extras.C) Yes. I did the following. The binary still exhibits the problem I posted about at the beginning of this thread (Unable to determine path...). Index: src/support/fs_extras.C === RCS file: /cvs/lyx/lyx-devel/src/support/fs_extras.C,v retrieving revision 1.2 diff -u -r1.2 fs_extras.C --- src/support/fs_extras.C 2005/01/31 19:31:11 1.2 +++ src/support/fs_extras.C 2005/02/01 15:46:41 @@ -13,6 +13,10 @@ #include sys/stat.h #include fcntl.h +#if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) || defined(__CYGWIN__) +#include windows.h +#endif + // BOOST_POSIX or BOOST_WINDOWS specify which API to use. # if !defined( BOOST_WINDOWS ) !defined( BOOST_POSIX ) # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) || defined(__CYGWIN__)
Re: The latest patches break cygwin again
Kayvan A. Sylvan wrote: Index: src/support/fs_extras.C === RCS file: /cvs/lyx/lyx-devel/src/support/fs_extras.C,v retrieving revision 1.2 diff -u -r1.2 fs_extras.C --- src/support/fs_extras.C 2005/01/31 19:31:11 1.2 +++ src/support/fs_extras.C 2005/02/01 15:46:41 @@ -13,6 +13,10 @@ #include sys/stat.h #include fcntl.h +#if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) || defined(__CYGWIN__) +#include windows.h +#endif + // BOOST_POSIX or BOOST_WINDOWS specify which API to use. # if !defined( BOOST_WINDOWS ) !defined( BOOST_POSIX ) # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) || # defined(__CYGWIN__) I'm about to commit the equivalent: @@ -22,6 +22,11 @@ # endif # endif +#if defined (BOOST_WINDOWS) +# define WIN32_LEAN_AND_MEAN +# include windows.h +#endif + namespace fs = boost::filesystem; -- Angus
Re: The latest patches break cygwin again
Angus Leeming [EMAIL PROTECTED] writes: | I'm about to commit the equivalent: | @@ -22,6 +22,11 @@ | # endif | # endif | +#if defined (BOOST_WINDOWS) | +# define WIN32_LEAN_AND_MEAN | +# include windows.h | +#endif If that is what is used in boost them ok. Else please use the same as boost uses. -- Lgb
Re: The latest patches break cygwin again
Lars Gullik Bjønnes wrote: | +#if defined (BOOST_WINDOWS) | +# define WIN32_LEAN_AND_MEAN | +# include windows.h | +#endif If that is what is used in boost them ok. Else please use the same as boost uses. Lars, get a grip please. Your commit was broken. It now works. The code is clean. So why the gripe? -- Angus
Re: The latest patches break cygwin again
Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | +#if defined (BOOST_WINDOWS) | +# define WIN32_LEAN_AND_MEAN | +# include windows.h | +#endif If that is what is used in boost them ok. Else please use the same as boost uses. | Lars, get a grip please. Your commit was broken. It now works. The code is | clean. So why the gripe? Eh? what have I done now? I just want fs_extras to compilie in the same environment as the regular boost filesystem code. -- Lgb
Re: The latest patches break cygwin again
On Tue, Feb 01, 2005 at 04:53:50PM +, Angus Leeming wrote: Lars Gullik Bjønnes wrote: | +#if defined (BOOST_WINDOWS) | +# define WIN32_LEAN_AND_MEAN | +# include windows.h | +#endif If that is what is used in boost them ok. Else please use the same as boost uses. Lars, get a grip please. Your commit was broken. It now works. The code is clean. So why the gripe? The commit was broken. It now compiles. It still does not work (at least for Cygwin). Regardless of whether it is run in place or installed, I get the same message: Unable to determine the path to the LyX binary from the command line [...] If I give the full path to the binary, then I get: Unable to determine the system directory having searched [...] Angus, how do you want me to debug this? I have my working lyx binary installed under a different name, so this is not stopping me in my job hunting and school work. ---Kayvan
Re: The latest patches break cygwin again
Lars Gullik Bjønnes wrote: | Lars Gullik Bjønnes wrote: | +#if defined (BOOST_WINDOWS) | +# define WIN32_LEAN_AND_MEAN | +# include windows.h | +#endif If that is what is used in boost them ok. Else please use the same as boost uses. | Lars, get a grip please. Your commit was broken. It now works. The code | is clean. So why the gripe? Eh? what have I done now? I just want fs_extras to compilie in the same environment as the regular boost filesystem code. Either the above enables the file to compile or it doesn't, no? Not even Windows would use WIN32_LEAN_AND_MEAN to change the meaning of DWORD. It exists solely to enable the developer to not drag in every single header file in the entire machine. What's the harm? -- Angus
Re: The latest patches break cygwin again
Kayvan A. Sylvan [EMAIL PROTECTED] writes: | Regardless of whether it is run in place or installed, I get the same | message: | Unable to determine the path to the LyX binary from the command line [...] | If I give the full path to the binary, then I get: | Unable to determine the system directory having searched [...] | Angus, how do you want me to debug this? I have my working lyx binary installed | under a different name, so this is not stopping me in my job hunting and | school work. My guess is that this is a cygwin Win or Posix thingie. What happens if you force the boost.filesystem to compile cygwin as posix? I know that this is not the easiest thing to change... it involves changing boost/libs/filesystem/src: exception.cpp operations_posix_windows.cpp path_posix_windows.cpp Actually... easy solution... make sure that BOOST_POSIX is defined. f.ex in our config.h. put #define BOOST_POSIX 1 there If that fixes cygwin, then we know what is wrong. -- Lgb
Re: The latest patches break cygwin again
Lars Gullik Bjønnes wrote: | Either the above enables the file to compile or it doesn't, no? Not | even Windows would use WIN32_LEAN_AND_MEAN to change the meaning of | DWORD. It exists solely to enable the developer to not drag in every | single header file in the entire machine. What's the harm? *sigh* I have said nothing about harm... I didn't even comment on the LEAN_AND_MEAN, I just want: fs_extras to compilie in the same environment as the regular boost filesystem code. *sigh* Bad day. Sorry. However, I don't get your meaning. Must be thick. -- Angus
Re: The latest patches break cygwin again
Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | Either the above enables the file to compile or it doesn't, no? Not | even Windows would use WIN32_LEAN_AND_MEAN to change the meaning of | DWORD. It exists solely to enable the developer to not drag in every | single header file in the entire machine. What's the harm? *sigh* I have said nothing about harm... I didn't even comment on the LEAN_AND_MEAN, I just want: fs_extras to compilie in the same environment as the regular boost filesystem code. | *sigh* Bad day. Sorry. However, I don't get your meaning. Must be thick. fs_extras is just an extension to boost.filesystem... se it should compile in the same environment using the same setup (headers and such...) -- Lgb
Re: The latest patches break cygwin again
Kayvan A. Sylvan [EMAIL PROTECTED] writes: | On Tue, Feb 01, 2005 at 07:08:14PM +0100, Lars Gullik Bjønnes wrote: boost/libs/filesystem/src: exception.cpp operations_posix_windows.cpp path_posix_windows.cpp Actually... easy solution... make sure that BOOST_POSIX is defined. f.ex in our config.h. put #define BOOST_POSIX 1 | Yes, this works. Ok. Then we have to decide on the best way to handle this. If we just make BOOST_POSIX be set for cygwin, then it works for you. But for the next guy using cygwin it will break. So are there any kindo of configure tests we can use to discover the setting of win/posix kind of setup on cygwin? -- Lgb
Re: The latest patches break cygwin again
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Then we have to decide on the best way to handle this. | If we just make BOOST_POSIX be set for cygwin, then it works for you. | But for the next guy using cygwin it will break. | So are there any kindo of configure tests we can use to discover the | setting of win/posix kind of setup on cygwin? The simple solution for now is to just add a configure switch --enable-boost-posix (perhaps with a better name) Then we have an easy way to turn this on and off for systems that need it. -- Lgb
Re: The latest patches break cygwin again
On Wed, Feb 02, 2005 at 08:23:00AM +0100, Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Then we have to decide on the best way to handle this. | If we just make BOOST_POSIX be set for cygwin, then it works for you. | But for the next guy using cygwin it will break. | So are there any kindo of configure tests we can use to discover the | setting of win/posix kind of setup on cygwin? The simple solution for now is to just add a configure switch --enable-boost-posix (perhaps with a better name) Then we have an easy way to turn this on and off for systems that need it. Works for me, though I think that having Cygwin default to POSIX enabled is the right thing. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: The latest patches break cygwin again
Kayvan A. Sylvan [EMAIL PROTECTED] writes: | On Wed, Feb 02, 2005 at 08:23:00AM +0100, Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Then we have to decide on the best way to handle this. | If we just make BOOST_POSIX be set for cygwin, then it works for you. | But for the next guy using cygwin it will break. | So are there any kindo of configure tests we can use to discover the | setting of win/posix kind of setup on cygwin? The simple solution for now is to just add a configure switch --enable-boost-posix (perhaps with a better name) Then we have an easy way to turn this on and off for systems that need it. | Works for me, though I think that having Cygwin default to POSIX enabled | is the right thing. If we only could convince all cygwin users to setup their systems like that... -- Lgb
Re: The latest patches break cygwin again
On Wed, Feb 02, 2005 at 08:30:25AM +0100, Lars Gullik Bjønnes wrote: Kayvan A. Sylvan [EMAIL PROTECTED] writes: | On Wed, Feb 02, 2005 at 08:23:00AM +0100, Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Then we have to decide on the best way to handle this. | If we just make BOOST_POSIX be set for cygwin, then it works for you. | But for the next guy using cygwin it will break. | So are there any kindo of configure tests we can use to discover the | setting of win/posix kind of setup on cygwin? The simple solution for now is to just add a configure switch --enable-boost-posix (perhaps with a better name) Then we have an easy way to turn this on and off for systems that need it. | Works for me, though I think that having Cygwin default to POSIX enabled | is the right thing. If we only could convince all cygwin users to setup their systems like that... I have done no modifications. This laptop is in fact a pristine setup with the latest Cygwin, running Cygwin tetex. I think it's reasonable to default to POSIX enabled for Cygwin. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: The latest patches break cygwin again
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | I just tried compiling latest CVS again. Here is what happens: > | g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src | -I../../../lyx/src/support/.. -I../../../lyx/boost -I/usr/local/include | -W -Wall -I/usr/X11R6/include -O2 -fno-exceptions -mms-bitfields | -MT fs_extras.lo -MD -MP -MF .deps/fs_extras.Tpo -c | ../../../lyx/src/support/fs_extras.C -o fs_extras.o > | ../../../lyx/src/support/fs_extras.C: In function `bool |boost::filesystem::is_readable(const boost::filesystem::path&)': | ../../../lyx/src/support/fs_extras.C:36: error: `DWORD' undeclared (first use Does it help if you add a #include to this file (fs_extras.C) -- Lgb
Re: The latest patches break cygwin again
On Tue, Feb 01, 2005 at 10:59:47AM +0100, Lars Gullik Bjønnes wrote:
> "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
>
> | I just tried compiling latest CVS again. Here is what happens:
> >
> | g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src
> | -I../../../lyx/src/support/.. -I../../../lyx/boost -I/usr/local/include
> | -W -Wall -I/usr/X11R6/include -O2 -fno-exceptions -mms-bitfields
> | -MT fs_extras.lo -MD -MP -MF .deps/fs_extras.Tpo -c
> | ../../../lyx/src/support/fs_extras.C -o fs_extras.o
> >
> | ../../../lyx/src/support/fs_extras.C: In function `bool
> |boost::filesystem::is_readable(const boost::filesystem::path&)':
> | ../../../lyx/src/support/fs_extras.C:36: error: `DWORD' undeclared (first
> use
>
> Does it help if you add a
>
> #include
>
> to this file (fs_extras.C)
Yes. I did the following. The binary still exhibits the problem I posted
about at the beginning of this thread ("Unable to determine path...").
Index: src/support/fs_extras.C
===
RCS file: /cvs/lyx/lyx-devel/src/support/fs_extras.C,v
retrieving revision 1.2
diff -u -r1.2 fs_extras.C
--- src/support/fs_extras.C 2005/01/31 19:31:11 1.2
+++ src/support/fs_extras.C 2005/02/01 15:46:41
@@ -13,6 +13,10 @@
#include
#include
+#if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) ||
defined(__CYGWIN__)
+#include
+#endif
+
// BOOST_POSIX or BOOST_WINDOWS specify which API to use.
# if !defined( BOOST_WINDOWS ) && !defined( BOOST_POSIX )
# if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) ||
defined(__CYGWIN__)
Re: The latest patches break cygwin again
Kayvan A. Sylvan wrote: > Index: src/support/fs_extras.C > === > RCS file: /cvs/lyx/lyx-devel/src/support/fs_extras.C,v > retrieving revision 1.2 > diff -u -r1.2 fs_extras.C > --- src/support/fs_extras.C 2005/01/31 19:31:11 1.2 > +++ src/support/fs_extras.C 2005/02/01 15:46:41 > @@ -13,6 +13,10 @@ > #include > #include > > +#if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) || > defined(__CYGWIN__) +#include > +#endif > + > // BOOST_POSIX or BOOST_WINDOWS specify which API to use. > # if !defined( BOOST_WINDOWS ) && !defined( BOOST_POSIX ) > # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) || > # defined(__CYGWIN__) I'm about to commit the equivalent: @@ -22,6 +22,11 @@ # endif # endif +#if defined (BOOST_WINDOWS) +# define WIN32_LEAN_AND_MEAN +# include +#endif + namespace fs = boost::filesystem; -- Angus
Re: The latest patches break cygwin again
Angus Leeming <[EMAIL PROTECTED]> writes: | I'm about to commit the equivalent: > | @@ -22,6 +22,11 @@ | # endif | # endif > | +#if defined (BOOST_WINDOWS) | +# define WIN32_LEAN_AND_MEAN | +# include | +#endif If that is what is used in boost them ok. Else please use the same as boost uses. -- Lgb
Re: The latest patches break cygwin again
Lars Gullik Bjønnes wrote: > | +#if defined (BOOST_WINDOWS) > | +# define WIN32_LEAN_AND_MEAN > | +# include > | +#endif > > If that is what is used in boost them ok. Else please use the same as > boost uses. Lars, get a grip please. Your commit was broken. It now works. The code is clean. So why the gripe? -- Angus
Re: The latest patches break cygwin again
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> | +#if defined (BOOST_WINDOWS) >> | +# define WIN32_LEAN_AND_MEAN >> | +# include >> | +#endif >> >> If that is what is used in boost them ok. Else please use the same as >> boost uses. > | Lars, get a grip please. Your commit was broken. It now works. The code is | clean. So why the gripe? Eh? what have I done now? I just want fs_extras to compilie in the same environment as the regular boost filesystem code. -- Lgb
Re: The latest patches break cygwin again
On Tue, Feb 01, 2005 at 04:53:50PM +, Angus Leeming wrote: > Lars Gullik Bjønnes wrote: > > | +#if defined (BOOST_WINDOWS) > > | +# define WIN32_LEAN_AND_MEAN > > | +# include > > | +#endif > > > > If that is what is used in boost them ok. Else please use the same as > > boost uses. > > Lars, get a grip please. Your commit was broken. It now works. The code is > clean. So why the gripe? The commit was broken. It now compiles. It still does not work (at least for Cygwin). Regardless of whether it is run in place or installed, I get the same message: "Unable to determine the path to the LyX binary from the command line [...]" If I give the full path to the binary, then I get: "Unable to determine the system directory having searched [...]" Angus, how do you want me to debug this? I have my working lyx binary installed under a different name, so this is not stopping me in my job hunting and school work. ---Kayvan
Re: The latest patches break cygwin again
Lars Gullik Bjønnes wrote: > | Lars Gullik Bjønnes wrote: >>> | +#if defined (BOOST_WINDOWS) >>> | +# define WIN32_LEAN_AND_MEAN >>> | +# include >>> | +#endif >>> >>> If that is what is used in boost them ok. Else please use the same as >>> boost uses. >> > | Lars, get a grip please. Your commit was broken. It now works. The code > | is clean. So why the gripe? > > Eh? what have I done now? > > I just want fs_extras to compilie in the same environment as the > regular boost filesystem code. Either the above enables the file to compile or it doesn't, no? Not even Windows would use WIN32_LEAN_AND_MEAN to change the meaning of DWORD. It exists solely to enable the developer to not drag in every single header file in the entire machine. What's the harm? -- Angus
Re: The latest patches break cygwin again
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | Regardless of whether it is run in place or installed, I get the same | message: > | "Unable to determine the path to the LyX binary from the command line [...]" > | If I give the full path to the binary, then I get: > | "Unable to determine the system directory having searched [...]" > | Angus, how do you want me to debug this? I have my working lyx binary installed | under a different name, so this is not stopping me in my job hunting and | school work. My guess is that this is a cygwin Win or Posix thingie. What happens if you force the boost.filesystem to compile cygwin as posix? I know that this is not the easiest thing to change... it involves changing boost/libs/filesystem/src: exception.cpp operations_posix_windows.cpp path_posix_windows.cpp Actually... easy solution... make sure that BOOST_POSIX is defined. f.ex in our config.h. put #define BOOST_POSIX 1 there If that fixes cygwin, then we know what is wrong. -- Lgb
Re: The latest patches break cygwin again
Lars Gullik Bjønnes wrote: > | Either the above enables the file to compile or it doesn't, no? Not > | even Windows would use WIN32_LEAN_AND_MEAN to change the meaning of > | DWORD. It exists solely to enable the developer to not drag in every > | single header file in the entire machine. What's the harm? > > *sigh* > > I have said nothing about harm... I didn't even comment on the > LEAN_AND_MEAN, I just want: > > "fs_extras to compilie in the same environment as the > regular boost filesystem code." *sigh* Bad day. Sorry. However, I don't get your meaning. Must be thick. -- Angus
Re: The latest patches break cygwin again
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> | Either the above enables the file to compile or it doesn't, no? Not >> | even Windows would use WIN32_LEAN_AND_MEAN to change the meaning of >> | DWORD. It exists solely to enable the developer to not drag in every >> | single header file in the entire machine. What's the harm? >> >> *sigh* >> >> I have said nothing about harm... I didn't even comment on the >> LEAN_AND_MEAN, I just want: >> >> "fs_extras to compilie in the same environment as the >> regular boost filesystem code." > | *sigh* Bad day. Sorry. However, I don't get your meaning. Must be thick. fs_extras is just an extension to boost.filesystem... se it should compile in the same environment using the same setup (headers and such...) -- Lgb
Re: The latest patches break cygwin again
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | On Tue, Feb 01, 2005 at 07:08:14PM +0100, Lars Gullik Bjønnes wrote: >> >> boost/libs/filesystem/src: >> exception.cpp >> operations_posix_windows.cpp >> path_posix_windows.cpp >> >> Actually... easy solution... make sure that BOOST_POSIX is defined. >> f.ex in our config.h. >> >> put >> >> #define BOOST_POSIX 1 > | Yes, this works. Ok. Then we have to decide on the best way to handle this. If we just make BOOST_POSIX be set for cygwin, then it works for you. But for the next guy using cygwin it will break. So are there any kindo of configure tests we can use to discover the setting of win/posix kind of setup on cygwin? -- Lgb
Re: The latest patches break cygwin again
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > | Then we have to decide on the best way to handle this. > | If we just make BOOST_POSIX be set for cygwin, then it works for you. | But for the next guy using cygwin it will break. > | So are there any kindo of configure tests we can use to discover the | setting of win/posix kind of setup on cygwin? The simple solution for now is to just add a configure switch "--enable-boost-posix" (perhaps with a better name) Then we have an easy way to turn this on and off for systems that need it. -- Lgb
Re: The latest patches break cygwin again
On Wed, Feb 02, 2005 at 08:23:00AM +0100, Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > > > > | Then we have to decide on the best way to handle this. > > > | If we just make BOOST_POSIX be set for cygwin, then it works for you. > | But for the next guy using cygwin it will break. > > > | So are there any kindo of configure tests we can use to discover the > | setting of win/posix kind of setup on cygwin? > > The simple solution for now is to just add a configure switch > "--enable-boost-posix" (perhaps with a better name) > > Then we have an easy way to turn this on and off for systems that need > it. Works for me, though I think that having Cygwin default to POSIX enabled is the right thing. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: The latest patches break cygwin again
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | On Wed, Feb 02, 2005 at 08:23:00AM +0100, Lars Gullik Bjønnes wrote: >> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: >> >> > >> | Then we have to decide on the best way to handle this. >> > >> | If we just make BOOST_POSIX be set for cygwin, then it works for you. >> | But for the next guy using cygwin it will break. >> > >> | So are there any kindo of configure tests we can use to discover the >> | setting of win/posix kind of setup on cygwin? >> >> The simple solution for now is to just add a configure switch >> "--enable-boost-posix" (perhaps with a better name) >> >> Then we have an easy way to turn this on and off for systems that need >> it. > | Works for me, though I think that having Cygwin default to POSIX enabled | is the right thing. If we only could convince all cygwin users to setup their systems like that... -- Lgb
Re: The latest patches break cygwin again
On Wed, Feb 02, 2005 at 08:30:25AM +0100, Lars Gullik Bjønnes wrote: > "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > > | On Wed, Feb 02, 2005 at 08:23:00AM +0100, Lars Gullik Bjønnes wrote: > >> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > >> > >> > > >> | Then we have to decide on the best way to handle this. > >> > > >> | If we just make BOOST_POSIX be set for cygwin, then it works for you. > >> | But for the next guy using cygwin it will break. > >> > > >> | So are there any kindo of configure tests we can use to discover the > >> | setting of win/posix kind of setup on cygwin? > >> > >> The simple solution for now is to just add a configure switch > >> "--enable-boost-posix" (perhaps with a better name) > >> > >> Then we have an easy way to turn this on and off for systems that need > >> it. > > > | Works for me, though I think that having Cygwin default to POSIX enabled > | is the right thing. > > If we only could convince all cygwin users to setup their systems like > that... I have done no modifications. This laptop is in fact a pristine setup with the latest Cygwin, running Cygwin tetex. I think it's reasonable to default to POSIX enabled for Cygwin. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: The latest patches break cygwin again
Kayvan A. Sylvan wrote: Hi Angus, Something in the latest patches broke the path finding code again on Cygwin. I am using the latest lyx-devel CVS. [EMAIL PROTECTED] ~/src/tex/lyx/resume] lyx resume.lyx Unable to determine the path to the LyX binary from the command line lyx [EMAIL PROTECTED] ~/src/tex/lyx/resume] /usr/local/bin/lyx resume.lyx Unable to determine the system directory having searched /usr/local/share/lyx/ Try the '-sysdir' command line parameter or set the environment variable LYX_DIR_13x to the LyX system directory containing the file `chkconfig.ltx'. The immediately prior checkout works just fine. In fact, I did a clean checkout with -D'01/30/2005' and compiled it to get a working Lyx. If anyone has any leads, feel free to throw them my way. See Lars' Kill FileInfo patch and my comment to it. http://article.gmane.org/gmane.editors.lyx.devel:41332 http://article.gmane.org/gmane.editors.lyx.devel:41350 -- Angus
Re: The latest patches break cygwin again
On Mon, Jan 31, 2005 at 07:47:56PM +, Angus Leeming wrote: See Lars' Kill FileInfo patch and my comment to it. http://article.gmane.org/gmane.editors.lyx.devel:41332 http://article.gmane.org/gmane.editors.lyx.devel:41350 lars - got rid of IsFileWriteable lars - got rid of DeleteAllFilesInDir lars - rewrote DirList angus H, I see it's gone in, but it looks to me like this patch has the angus potential to break Cygwin and Windows builds. Looks like you were right. What's the right fix? Lars? I'll be happy to test your fixes... ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: The latest patches break cygwin again
Kayvan A. Sylvan [EMAIL PROTECTED] writes: | On Mon, Jan 31, 2005 at 07:47:56PM +, Angus Leeming wrote: See Lars' Kill FileInfo patch and my comment to it. http://article.gmane.org/gmane.editors.lyx.devel:41332 http://article.gmane.org/gmane.editors.lyx.devel:41350 | lars - got rid of IsFileWriteable | lars - got rid of DeleteAllFilesInDir | lars - rewrote DirList | angus H, I see it's gone in, but it looks to me like this patch has the | angus potential to break Cygwin and Windows builds. | Looks like you were right. | What's the right fix? Lars? I'll be happy to test your fixes... I need a super detailed bug report. Without it I have no clue what goes wrong... (for all I know it is a couple of string() that should be native() ) -- Lgb
Re: The latest patches break cygwin again
On Mon, Jan 31, 2005 at 10:50:45PM +0100, Lars Gullik Bjønnes wrote: Kayvan A. Sylvan [EMAIL PROTECTED] writes: | On Mon, Jan 31, 2005 at 07:47:56PM +, Angus Leeming wrote: See Lars' Kill FileInfo patch and my comment to it. http://article.gmane.org/gmane.editors.lyx.devel:41332 http://article.gmane.org/gmane.editors.lyx.devel:41350 | lars - got rid of IsFileWriteable | lars - got rid of DeleteAllFilesInDir | lars - rewrote DirList | angus H, I see it's gone in, but it looks to me like this patch has the | angus potential to break Cygwin and Windows builds. | Looks like you were right. | What's the right fix? Lars? I'll be happy to test your fixes... I need a super detailed bug report. Without it I have no clue what goes wrong... (for all I know it is a couple of string() that should be native() ) Latest Cygwin, latest CVS build: $ ./src/lyx Unable to determine the path to the LyX binary from the command line ./src/lyx Using the absolute path: $ /home/kayvan/src/lyx/build/src/lyx Unable to determine the system directory having searched /home/kayvan/src/lyx/build/share/lyx/ Try the '-sysdir' command line parameter or set the environment variable LYX_DIR_13x to the LyX system directory containing the file `chkconfig.ltx'. Anything else you need? ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: The latest patches break cygwin again
Kayvan A. Sylvan wrote: I need a super detailed bug report. Without it I have no clue what goes wrong... (for all I know it is a couple of string() that should be native() ) Latest Cygwin, latest CVS build: $ ./src/lyx Unable to determine the path to the LyX binary from the command line ./src/lyx Using the absolute path: $ /home/kayvan/src/lyx/build/src/lyx Unable to determine the system directory having searched /home/kayvan/src/lyx/build/share/lyx/ Try the '-sysdir' command line parameter or set the environment variable LYX_DIR_13x to the LyX system directory containing the file `chkconfig.ltx'. Anything else you need? Kayvan, you're running with LyX in-place, right? Could you add a few print statements in src/support/packages.C.in ? Lars, the good news is that I have just compiled tex2lyx on a Windows machine and can run it successfully when the thing is installed. Din't manage to do so with it in-place, but there might be other reasons for that. -- Angus
Re: The latest patches break cygwin again
On Mon, Jan 31, 2005 at 10:50:18PM +, Angus Leeming wrote: Kayvan, you're running with LyX in-place, right? No. In place or installed, I get identical results. Could you add a few print statements in src/support/packages.C.in ? Sure. What kind? Where? ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: The latest patches break cygwin again
I just tried compiling latest CVS again. Here is what happens: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src -I../../../lyx/src/support/.. -I../../../lyx/boost -I/usr/local/include -W -Wall -I/usr/X11R6/include -O2 -fno-exceptions -mms-bitfields -MT fs_extras.lo -MD -MP -MF .deps/fs_extras.Tpo -c ../../../lyx/src/support/fs_extras.C -o fs_extras.o ../../../lyx/src/support/fs_extras.C: In function `bool boost::filesystem::is_readable(const boost::filesystem::path)': ../../../lyx/src/support/fs_extras.C:36: error: `DWORD' undeclared (first use this function) ../../../lyx/src/support/fs_extras.C:36: error: (Each undeclared identifier is reported only once for each function it appears in.) ../../../lyx/src/support/fs_extras.C:36: error: parse error before `const' ../../../lyx/src/support/fs_extras.C:37: error: `attr' undeclared (first use this function) ../../../lyx/src/support/fs_extras.C:37: error: `INVALID_FILE_ATTRIBUTES' undeclared (first use this function) ../../../lyx/src/support/fs_extras.C:38: error: `FILE_ATTRIBUTE_DIRECTORY' undeclared (first use this function) ../../../lyx/src/support/fs_extras.C:31: warning: unused parameter `const boost::filesystem::pathph' ../../../lyx/src/support/fs_extras.C: In function `bool boost::filesystem::is_writable(const boost::filesystem::path)': ../../../lyx/src/support/fs_extras.C:49: error: parse error before `const' ../../../lyx/src/support/fs_extras.C:51: error: `FILE_ATTRIBUTE_READONLY' undeclared (first use this function) ../../../lyx/src/support/fs_extras.C:44: warning: unused parameter `const boost::filesystem::pathph' ../../../lyx/src/support/fs_extras.C: In function `bool boost::filesystem::is_readonly(const boost::filesystem::path)': ../../../lyx/src/support/fs_extras.C:67: error: parse error before `const' ../../../lyx/src/support/fs_extras.C:62: warning: unused parameter `const boost::filesystem::pathph' ../../../lyx/src/support/fs_extras.C: In function `void boost::filesystem::copy_file(const boost::filesystem::path, const boost::filesystem::path, bool)': ../../../lyx/src/support/fs_extras.C:140: error: `::CopyFile' undeclared (first use here) make[5]: *** [fs_extras.lo] Error 1 make[5]: Leaving directory `/home/Kayvan/src/lyx/build/src/support' ---Kayvan
Re: The latest patches break cygwin again
Kayvan A. Sylvan wrote: > Hi Angus, > > Something in the latest patches broke the path finding code again on > Cygwin. I am using the latest lyx-devel CVS. > > [EMAIL PROTECTED] ~/src/tex/lyx/resume] lyx resume.lyx > Unable to determine the path to the LyX binary from the command line > lyx > > [EMAIL PROTECTED] ~/src/tex/lyx/resume] /usr/local/bin/lyx resume.lyx > Unable to determine the system directory having searched > /usr/local/share/lyx/ > Try the '-sysdir' command line parameter or set the environment > variable LYX_DIR_13x to the LyX system directory containing the file > `chkconfig.ltx'. > > The immediately prior checkout works just fine. In fact, I did > a clean checkout with -D'01/30/2005' and compiled it to get a > working Lyx. > > If anyone has any leads, feel free to throw them my way. See Lars' "Kill FileInfo" patch and my comment to it. http://article.gmane.org/gmane.editors.lyx.devel:41332 http://article.gmane.org/gmane.editors.lyx.devel:41350 -- Angus
Re: The latest patches break cygwin again
On Mon, Jan 31, 2005 at 07:47:56PM +, Angus Leeming wrote: > > See Lars' "Kill FileInfo" patch and my comment to it. > http://article.gmane.org/gmane.editors.lyx.devel:41332 > http://article.gmane.org/gmane.editors.lyx.devel:41350 > lars> - got rid of IsFileWriteable lars> - got rid of DeleteAllFilesInDir lars> - rewrote DirList angus> H, I see it's gone in, but it looks to me like this patch has the angus> potential to break Cygwin and Windows builds. Looks like you were right. What's the right fix? Lars? I'll be happy to test your fixes... ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: The latest patches break cygwin again
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | On Mon, Jan 31, 2005 at 07:47:56PM +, Angus Leeming wrote: >> >> See Lars' "Kill FileInfo" patch and my comment to it. >> http://article.gmane.org/gmane.editors.lyx.devel:41332 >> http://article.gmane.org/gmane.editors.lyx.devel:41350 >> > | lars> - got rid of IsFileWriteable | lars> - got rid of DeleteAllFilesInDir | lars> - rewrote DirList > | angus> H, I see it's gone in, but it looks to me like this patch has the | angus> potential to break Cygwin and Windows builds. > | Looks like you were right. > | What's the right fix? Lars? I'll be happy to test your fixes... I need a super detailed bug report. Without it I have no clue what goes wrong... (for all I know it is a couple of string() that should be native() ) -- Lgb
Re: The latest patches break cygwin again
On Mon, Jan 31, 2005 at 10:50:45PM +0100, Lars Gullik Bjønnes wrote: > "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > > | On Mon, Jan 31, 2005 at 07:47:56PM +, Angus Leeming wrote: > >> > >> See Lars' "Kill FileInfo" patch and my comment to it. > >> http://article.gmane.org/gmane.editors.lyx.devel:41332 > >> http://article.gmane.org/gmane.editors.lyx.devel:41350 > >> > > > | lars> - got rid of IsFileWriteable > | lars> - got rid of DeleteAllFilesInDir > | lars> - rewrote DirList > > > | angus> H, I see it's gone in, but it looks to me like this patch has > the > | angus> potential to break Cygwin and Windows builds. > > > | Looks like you were right. > > > | What's the right fix? Lars? I'll be happy to test your fixes... > > I need a super detailed bug report. > Without it I have no clue what goes wrong... > (for all I know it is a couple of string() that should be native() ) Latest Cygwin, latest CVS build: $ ./src/lyx Unable to determine the path to the LyX binary from the command line ./src/lyx Using the absolute path: $ /home/kayvan/src/lyx/build/src/lyx Unable to determine the system directory having searched /home/kayvan/src/lyx/build/share/lyx/ Try the '-sysdir' command line parameter or set the environment variable LYX_DIR_13x to the LyX system directory containing the file `chkconfig.ltx'. Anything else you need? ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: The latest patches break cygwin again
Kayvan A. Sylvan wrote: >> I need a super detailed bug report. >> Without it I have no clue what goes wrong... >> (for all I know it is a couple of string() that should be native() ) > > Latest Cygwin, latest CVS build: > > $ ./src/lyx > Unable to determine the path to the LyX binary from the command line > ./src/lyx > > Using the absolute path: > > $ /home/kayvan/src/lyx/build/src/lyx > Unable to determine the system directory having searched > /home/kayvan/src/lyx/build/share/lyx/ > Try the '-sysdir' command line parameter or set the environment > variable LYX_DIR_13x to the LyX system directory containing the file > `chkconfig.ltx'. > > Anything else you need? Kayvan, you're running with LyX in-place, right? Could you add a few print statements in src/support/packages.C.in ? Lars, the good news is that I have just compiled tex2lyx on a Windows machine and can run it successfully when the thing is installed. Din't manage to do so with it in-place, but there might be other reasons for that. -- Angus
Re: The latest patches break cygwin again
On Mon, Jan 31, 2005 at 10:50:18PM +, Angus Leeming wrote: > Kayvan, you're running with LyX in-place, right? No. In place or installed, I get identical results. > Could you add a few print statements in src/support/packages.C.in ? Sure. What kind? Where? ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: The latest patches break cygwin again
I just tried compiling latest CVS again. Here is what happens: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src -I../../../lyx/src/support/.. -I../../../lyx/boost -I/usr/local/include -W -Wall -I/usr/X11R6/include -O2 -fno-exceptions -mms-bitfields -MT fs_extras.lo -MD -MP -MF .deps/fs_extras.Tpo -c ../../../lyx/src/support/fs_extras.C -o fs_extras.o ../../../lyx/src/support/fs_extras.C: In function `bool boost::filesystem::is_readable(const boost::filesystem::path&)': ../../../lyx/src/support/fs_extras.C:36: error: `DWORD' undeclared (first use this function) ../../../lyx/src/support/fs_extras.C:36: error: (Each undeclared identifier is reported only once for each function it appears in.) ../../../lyx/src/support/fs_extras.C:36: error: parse error before `const' ../../../lyx/src/support/fs_extras.C:37: error: `attr' undeclared (first use this function) ../../../lyx/src/support/fs_extras.C:37: error: `INVALID_FILE_ATTRIBUTES' undeclared (first use this function) ../../../lyx/src/support/fs_extras.C:38: error: `FILE_ATTRIBUTE_DIRECTORY' undeclared (first use this function) ../../../lyx/src/support/fs_extras.C:31: warning: unused parameter `const boost::filesystem::path' ../../../lyx/src/support/fs_extras.C: In function `bool boost::filesystem::is_writable(const boost::filesystem::path&)': ../../../lyx/src/support/fs_extras.C:49: error: parse error before `const' ../../../lyx/src/support/fs_extras.C:51: error: `FILE_ATTRIBUTE_READONLY' undeclared (first use this function) ../../../lyx/src/support/fs_extras.C:44: warning: unused parameter `const boost::filesystem::path' ../../../lyx/src/support/fs_extras.C: In function `bool boost::filesystem::is_readonly(const boost::filesystem::path&)': ../../../lyx/src/support/fs_extras.C:67: error: parse error before `const' ../../../lyx/src/support/fs_extras.C:62: warning: unused parameter `const boost::filesystem::path' ../../../lyx/src/support/fs_extras.C: In function `void boost::filesystem::copy_file(const boost::filesystem::path&, const boost::filesystem::path&, bool)': ../../../lyx/src/support/fs_extras.C:140: error: `::CopyFile' undeclared (first use here) make[5]: *** [fs_extras.lo] Error 1 make[5]: Leaving directory `/home/Kayvan/src/lyx/build/src/support' ---Kayvan
