Hi!
Here is a first draft version of VCDiff windows support. It behaves exactly like the linux versions, the diff is copied in a new tab.
It uses its own spawn functions based on CreateProcess and CreatePipe. Ideally we may create a common wrapper for all platform specific spawn (until glib works correctly). It is not yet complete as I was not sure about the error management in geany,. I use mix of printf and dialog boxes for now. What is the common method to tell the user that something went wrong? And which kind of error (or level of details) do we display?
Comments, feedbacks welcome,
Cheers
On Mon, 18 Feb 2008 16:45:46 +0100, "Pierre Joye" pierre.php@gmail.com wrote:
Hi,
Here is a first draft version of VCDiff windows support. It behaves
Cool, looks fine. There seems to be a little problem with the "Diff from current file" action: it seems it generates always a diff from the directory of the current file instead of the current file itself. I didn't do much testing but I guess it's only a small error.
It uses its own spawn functions based on CreateProcess and CreatePipe. Ideally we may create a common wrapper for all platform specific spawn (until glib works correctly). It is not yet complete as I was not sure
Yes, this would be a good idea and especially to save duplicate code because we need your code in Geany, in the vcdiff plugin and Frank and Yura probably want to use it also in their GeanyVC plugin. Not to mention any other plugins which want to execute some programs on Windows. Maybe we should put your code into src/win32.c. And we create a wrapper function for g_spawn_sync() and g_spawn_async() which just call these functions on non-Windows systems, else the Win32 specific versions. Could you also create a geany_w32_spawn_async()?
And we should file a bug report in GLib's bugzilla.
about the error management in geany,. I use mix of printf and dialog boxes for now. What is the common method to tell the user that something went wrong? And which kind of error (or level of details) do we display?
We never defined explicit rules for displaying error messages, but in general it's something like this: - real errors (ongoing action could not be performed): dialog box - common errors & warnings (action could not performed completely or not as expected): status bar - all other things should go to the conosle with geany_debug().
Regards, Enrico
Hi Enrico,
On Feb 18, 2008 6:18 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Mon, 18 Feb 2008 16:45:46 +0100, "Pierre Joye" pierre.php@gmail.com wrote:
Hi,
Here is a first draft version of VCDiff windows support. It behaves
Cool, looks fine. There seems to be a little problem with the "Diff from current file" action: it seems it generates always a diff from the directory of the current file instead of the current file itself.
I don't understand what you mean, the two "current file"s confuse me :)
I didn't do much testing but I guess it's only a small error.
It uses its own spawn functions based on CreateProcess and CreatePipe. Ideally we may create a common wrapper for all platform specific spawn (until glib works correctly). It is not yet complete as I was not sure
Yes, this would be a good idea and especially to save duplicate code because we need your code in Geany, in the vcdiff plugin and Frank and Yura probably want to use it also in their GeanyVC plugin. Not to mention any other plugins which want to execute some programs on Windows. Maybe we should put your code into src/win32.c. And we create a wrapper function for g_spawn_sync() and g_spawn_async() which just call these functions on non-Windows systems, else the Win32 specific versions. Could you also create a geany_w32_spawn_async()?
I first tried to do that but win32 functions are not exported and thus not callable by plugins. It will require a dllexport first (and probably some def files too). However I agree, the win32 function fits best there. The "geany_spawn_async()" may be put somewhere else, cmd_invoke.c and exposed (for the plugins), thoughts?
And we should file a bug report in GLib's bugzilla.
Yes, I will have to create a small app to reproduce the problem and see if it is fixable in glib.
about the error management in geany,. I use mix of printf and dialog boxes for now. What is the common method to tell the user that something went wrong? And which kind of error (or level of details) do we display?
We never defined explicit rules for displaying error messages, but in general it's something like this:
- real errors (ongoing action could not be performed): dialog box
- common errors & warnings (action could not performed completely or not
as expected): status bar
- all other things should go to the conosle with geany_debug().
Ah did not know about geany_debug, thanks!
On Mon, 18 Feb 2008 18:35:19 +0100, "Pierre Joye" pierre.php@gmail.com wrote:
Hi Enrico,
On Feb 18, 2008 6:18 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Mon, 18 Feb 2008 16:45:46 +0100, "Pierre Joye" pierre.php@gmail.com wrote:
Hi,
Here is a first draft version of VCDiff windows support. It behaves
Cool, looks fine. There seems to be a little problem with the "Diff from current file" action: it seems it generates always a diff from the directory of the current file instead of the current file itself.
I don't understand what you mean, the two "current file"s confuse me :)
Sorry, I should read what I'm writing before hitting the send button :D. Steps to reproduce: - Geany working copy, only plugins/vcdiff.c is modified, all other files are unmodified from SVN - start Geany and open the file ChangeLog from this working copy - then Tools->VCdiff->From Current File - instead of reporting "No changes were made", it shows the changes from plugins/vcdiff.c
If more files are changed, these diffs are also shown. So, I guess passing the file argument to the svn command line seems to be broken.
I didn't do much testing but I guess it's only a small error.
It uses its own spawn functions based on CreateProcess and CreatePipe. Ideally we may create a common wrapper for all platform specific spawn (until glib works correctly). It is not yet complete as I was not sure
Yes, this would be a good idea and especially to save duplicate code because we need your code in Geany, in the vcdiff plugin and Frank and Yura probably want to use it also in their GeanyVC plugin. Not to mention any other plugins which want to execute some programs on Windows. Maybe we should put your code into src/win32.c. And we create a wrapper function for g_spawn_sync() and g_spawn_async() which just call these functions on non-Windows systems, else the Win32 specific versions. Could you also create a geany_w32_spawn_async()?
I first tried to do that but win32 functions are not exported and thus not callable by plugins. It will require a dllexport first (and probably some def files too). However I agree, the win32 function fits
Why? I was talking about to add your code simply to Geany's core code. There we create the wrapper functions, maybe utils_spawn_sync() and utils_spawn_async(). Within these wrappers depending on the operating system at compile time, your code (on Windows) or the GLib implementations (on non-Windows platforms) are called. All this happens inside Geany. Then we add these wrapper functions to the plugin API just like any other function in Geany. So, plugins don't know anything about all the different handling, they just use Geany's utils_spawn_sync() and the correct code is executed by Geany.
Regards, Enrico
On Mon, 18 Feb 2008 20:46:26 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
I first tried to do that but win32 functions are not exported and thus not callable by plugins. It will require a dllexport first (and probably some def files too). However I agree, the win32 function fits
Why? I was talking about to add your code simply to Geany's core code. There we create the wrapper functions, maybe utils_spawn_sync() and utils_spawn_async(). Within these wrappers depending on the operating system at compile time, your code (on Windows) or the GLib implementations (on non-Windows platforms) are called. All this happens inside Geany. Then we add these wrapper functions to the plugin API just like any other function in Geany. So, plugins don't know anything about all the different handling, they just use Geany's utils_spawn_sync() and the correct code is executed by Geany.
If this works, this would be a great things for plugins. So I agree ;)
Regards, Frank
HI,
On Feb 18, 2008 8:46 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
I don't understand what you mean, the two "current file"s confuse me :)
Sorry, I should read what I'm writing before hitting the send button :D. Steps to reproduce:
- Geany working copy, only plugins/vcdiff.c is modified, all other
files are unmodified from SVN
- start Geany and open the file ChangeLog from this working copy
- then Tools->VCdiff->From Current File
- instead of reporting "No changes were made", it shows the changes
from plugins/vcdiff.c
If more files are changed, these diffs are also shown. So, I guess passing the file argument to the svn command line seems to be broken.
I didn't do much testing but I guess it's only a small error.
It uses its own spawn functions based on CreateProcess and CreatePipe. Ideally we may create a common wrapper for all platform specific spawn (until glib works correctly). It is not yet complete as I was not sure
Yes, this would be a good idea and especially to save duplicate code because we need your code in Geany, in the vcdiff plugin and Frank and Yura probably want to use it also in their GeanyVC plugin. Not to mention any other plugins which want to execute some programs on Windows. Maybe we should put your code into src/win32.c. And we create a wrapper function for g_spawn_sync() and g_spawn_async() which just call these functions on non-Windows systems, else the Win32 specific versions. Could you also create a geany_w32_spawn_async()?
I first tried to do that but win32 functions are not exported and thus not callable by plugins. It will require a dllexport first (and probably some def files too). However I agree, the win32 function fits
Then we add these wrapper functions to the plugin API just like any other function in Geany. So, plugins don't know anything about all the different handling, they just use Geany's utils_spawn_sync() and the correct code is executed by Geany.
The last paragraph is what I meant, create a wrapper around the OS specific functions and export it via the plugin API. My first attempt was to use the win32.c function directly.
Attached is an updated version, the changes are: - Fixed bug when diffing a single file - stderr support implemented (function sets now both stdout and stderr - a couple of leaks and error checks - a bit cleaner
What I still have to do is: - display errors using the various UI methods when necessary - move the win32 codes to win32.c - add utils_spawn_sync to the struct UtilsFuncs
I don't see a need of async call right now, I will implement sync only for now. However, on windows it will be async anyway, but I don't feel confortable enough with geany to go down the road of non blocking async IO for the plugins, maybe later :)
let me know how it works and what you like to add/change,
Cheers,
On Tue, 19 Feb 2008 02:44:40 +0100, "Pierre Joye" pierre.php@gmail.com wrote:
Hi,
Then we add these wrapper functions to the plugin API just like any other function in Geany. So, plugins don't know anything about all the different handling, they just use Geany's utils_spawn_sync() and the correct code is executed by Geany.
The last paragraph is what I meant, create a wrapper around the OS specific functions and export it via the plugin API. My first attempt was to use the win32.c function directly.
With the plugin API you don't need any dllexports (what a luck :D).
Attached is an updated version, the changes are:
- Fixed bug when diffing a single file
- stderr support implemented (function sets now both stdout and stderr
- a couple of leaks and error checks
- a bit cleaner
I'll give it a try, thanks.
What I still have to do is:
- display errors using the various UI methods when necessary
Do it like you think it's good, or just use geany_debug() for now. This can be improved once the code itself is working.
- move the win32 codes to win32.c
- add utils_spawn_sync to the struct UtilsFuncs
You can also skip this and leave it to be done by me. No problem, it's just moving code.
I don't see a need of async call right now, I will implement sync only for now. However, on windows it will be async anyway, but I don't feel confortable enough with geany to go down the road of non blocking async IO for the plugins, maybe later :)
Hmmm, async process spawning is used inside Geany for the build commands. It's better to run compiler and make processes asynchronous to avoid a frozen GUI while waiting for the process to finish. If the process calling on Windows is always async, then it doesn't matter. The g_spawn_sync* calls in the vcdiff plugin were only because it is sufficient at this point(a svn diff doesn't take very long in usually) and the g_spawn_sync is just simpler to use.
But in Geany we need, or at least we want, the more sophisticated syntax of the async calls to read from the stdout and stderr pipes while the command is executed. Would this also be possible with your code? If not, it's not a big problem. This would only mean, when compiling some code on Windows inside Geany, the compiler output wouldn't be inserted "live" in the messages window but complete once the process finished.
Thank you very much for your efforts.
Regards, Enrico
Hi Enrico,
On Feb 19, 2008 10:44 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
What I still have to do is:
- display errors using the various UI methods when necessary
Do it like you think it's good, or just use geany_debug() for now. This can be improved once the code itself is working.
Ok, I will use dialogs for failure and status bar for the notices.
- move the win32 codes to win32.c
- add utils_spawn_sync to the struct UtilsFuncs
You can also skip this and leave it to be done by me. No problem, it's just moving code.
I can try to finish it later today or during the weekend.
I don't see a need of async call right now, I will implement sync only for now. However, on windows it will be async anyway, but I don't feel confortable enough with geany to go down the road of non blocking async IO for the plugins, maybe later :)
Hmmm, async process spawning is used inside Geany for the build commands. It's better to run compiler and make processes asynchronous to avoid a frozen GUI while waiting for the process to finish. If the process calling on Windows is always async, then it doesn't matter. The g_spawn_sync* calls in the vcdiff plugin were only because it is sufficient at this point(a svn diff doesn't take very long in usually) and the g_spawn_sync is just simpler to use.
But in Geany we need, or at least we want, the more sophisticated syntax of the async calls to read from the stdout and stderr pipes while the command is executed. Would this also be possible with your code?
Yes, windows does it asynchronously already. Then one will have to call WaitForChild or use some kind of events. It is done implicitely now.
If not, it's not a big problem. This would only mean, when compiling some code on Windows inside Geany, the compiler output wouldn't be inserted "live" in the messages window but complete once the process finished.
Oh right, compilation and other similar tasks may take longer. I have to take a look at how you use it and how you manage the display of stdout/stderr. It should not be that hard to adapt my code to do the same (The hard part is done now, we get stdout and stderr ;)
Thank you very much for your efforts.
You are welcome, it was a big opportunitiy to give something back to my favorite editor (with GUI :-)
Cheers,
HI!
On Feb 19, 2008 12:47 PM, Pierre Joye pierre.php@gmail.com wrote:
Oh right, compilation and other similar tasks may take longer. I have to take a look at how you use it and how you manage the display of stdout/stderr. It should not be that hard to adapt my code to do the same (The hard part is done now, we get stdout and stderr ;)
Please find the updated patch as attachment. The changes are:
- moved the windows API usage and functions to win32.* - remove all dialog but when STDERR is not empty, other errors are now printf'ed to stderr (can use geany_debug later) - add utils_spawn_sync and utils_spawn_sync to the utils plugin API. Only utils_spawn_sync is yet implemented
The signature of utils_spawn_sync is nearly the same as the glib's one. What differs now for windows is:
- GSpawnChildSetupFunc child_setup, gpointer user_data are not used (not implemented yet) - Only the PATH flag is used (have to verify what do the other - GError can't be implemented
It should work well for vcdiff or the "VC" plugin. I have to learn a bit more about what needs geany (like in builds or run cmd) before going further with the async version and callbacks.
Comments, ideas, feedbacks welcome,
Cheers,
Attached the wrong patch, linux did not use the new plugin function.
Also added $(MAKE) variable for mingw Makefiles, instead of statically defined "make". My install has mingw32- as prefix for all gnu cmd and only some exists without.
Hi!
On Wed, Feb 20, 2008 at 4:42 PM, Pierre Joye pierre.php@gmail.com wrote:
Attached the wrong patch, linux did not use the new plugin function.
Also added $(MAKE) variable for mingw Makefiles, instead of statically defined "make". My install has mingw32- as prefix for all gnu cmd and only some exists without.
Any news on this front? Do you need anything more before a commit?
By the way, add a ) in the make_diff function for the non windows version, I testes the patch earlier today and notices this typo :D
Cheers
On Thu, 21 Feb 2008 17:03:20 +0100, "Pierre Joye" pierre.php@gmail.com wrote:
Hi!
On Wed, Feb 20, 2008 at 4:42 PM, Pierre Joye pierre.php@gmail.com wrote:
Attached the wrong patch, linux did not use the new plugin function.
Also added $(MAKE) variable for mingw Makefiles, instead of statically defined "make". My install has mingw32- as prefix for all gnu cmd and only some exists without.
Any news on this front? Do you need anything more before a commit?
I'll have a look at it tomorrow and then I'll commit it, thanks so far. Please be patient...
By the way, add a ) in the make_diff function for the non windows version, I testes the patch earlier today and notices this typo :D
;-)
Regards, Enrico
On Thu, Feb 21, 2008 at 5:28 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 21 Feb 2008 17:03:20 +0100, "Pierre Joye"
pierre.php@gmail.com wrote:
Hi!
On Wed, Feb 20, 2008 at 4:42 PM, Pierre Joye pierre.php@gmail.com wrote:
Attached the wrong patch, linux did not use the new plugin function.
Also added $(MAKE) variable for mingw Makefiles, instead of statically defined "make". My install has mingw32- as prefix for all gnu cmd and only some exists without.
Any news on this front? Do you need anything more before a commit?
I'll have a look at it tomorrow and then I'll commit it, thanks so far. Please be patient...
Oh sorry, I did not mean it as "do it now!", I was only wondering if I forgot something important :)
I can wait a lot, I use sources on both windows and unix :)
By the way, add a ) in the make_diff function for the non windows version, I testes the patch earlier today and notices this typo :D
;-)
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.key
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, 21 Feb 2008 17:32:40 +0100, "Pierre Joye" pierre.php@gmail.com wrote:
On Thu, Feb 21, 2008 at 5:28 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 21 Feb 2008 17:03:20 +0100, "Pierre Joye"
pierre.php@gmail.com wrote:
Hi!
On Wed, Feb 20, 2008 at 4:42 PM, Pierre Joye pierre.php@gmail.com wrote:
Attached the wrong patch, linux did not use the new plugin function.
Also added $(MAKE) variable for mingw Makefiles, instead of statically defined "make". My install has mingw32- as prefix for all gnu cmd and only some exists without.
Any news on this front? Do you need anything more before a commit?
I'll have a look at it tomorrow and then I'll commit it, thanks so far. Please be patient...
Oh sorry, I did not mean it as "do it now!", I was only wondering if I forgot something important :)
I can wait a lot, I use sources on both windows and unix :)
Finally, I added the code to my local working copy and I'll commit the code soon (the Subversion repository at Sourceforge is currently not accessible).
Changes: - renamed geany_w32_spawn_sync in win32_spawn - added utils_spawn_async() which calls g_spawn_async() on non-Win32 systems, else it calls win32_spawn (for now) - added GError argument to utils_spawn_* functions - made helper functions in win32.c static - some little coding style changes, just cosmetics
Questions: You told win32_spawn() always creates processes asynchronous? If so, it should be ok to use it for g_spawn_sync and g_spawn_async calls, right? I must admit I didn't test the code much, yet.
Do you think it's possible to create g_spawn_async_with_pipes() on Windows? We use the _with_pipes variant for the whole Build system code as well as for the Custom commands and Find in Files search. This doesn't need to be exported to the plugin API but it would be really useful in Geany itself. But only if you like to and if you have time for it.
Regards, Enrico
On Sat, Feb 23, 2008 at 11:32 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
Do you think it's possible to create g_spawn_async_with_pipes() on Windows ... This doesn't need to be exported to the plugin API ...
If I may inject my 2c here, I managed to get the GDB plugin to compile and load on Windows - but it seems to suffer from the same problem, that is, its pipes don't read or write anything. So if someone does manage to get an async_with_pipes working for windows, I would like to see it available also for plugins, since the GeanyDebug plugin needs two-way communication with gdb.
- Jeff
On Sat, Feb 23, 2008 at 6:57 PM, Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
On Sat, Feb 23, 2008 at 11:32 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
Do you think it's possible to create g_spawn_async_with_pipes() on Windows ... This doesn't need to be exported to the plugin API ...
If I may inject my 2c here, I managed to get the GDB plugin to compile and load on Windows - but it seems to suffer from the same problem, that is, its pipes don't read or write anything. So if someone does manage to get an async_with_pipes working for windows, I would like to see it available also for plugins, since the GeanyDebug plugin needs two-way communication with gdb.
That looks like a very good reason for me to sit down and begin work (well, on Monday, it's the weekend after all ;)
On Sat, 23 Feb 2008 19:15:52 +0100, "Pierre Joye" pierre.php@gmail.com wrote:
On Sat, Feb 23, 2008 at 6:57 PM, Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
On Sat, Feb 23, 2008 at 11:32 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
Do you think it's possible to create g_spawn_async_with_pipes() on Windows ... This doesn't need to be exported to the plugin API ...
-> it does need to be exported, see below.
If I may inject my 2c here, I managed to get the GDB plugin to compile and load on Windows - but it seems to suffer from the same problem, that is, its pipes don't read or write anything. So if someone does manage to get an async_with_pipes working for windows, I would like to see it available also for plugins, since the GeanyDebug plugin needs two-way
ok, see above :D.
That looks like a very good reason for me to sit down and begin work (well, on Monday, it's the weekend after all ;)
Don't hurry. First enjoy your weekend, the code can also be written next week :D.
Regards, Enrico
Hi Enrico,
On Sat, Feb 23, 2008 at 6:32 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
I can wait a lot, I use sources on both windows and unix :)
Finally, I added the code to my local working copy and I'll commit the code soon (the Subversion repository at Sourceforge is currently not accessible).
That's great news, thanks!
Changes:
- renamed geany_w32_spawn_sync in win32_spawn
- added utils_spawn_async() which calls g_spawn_async() on non-Win32
systems, else it calls win32_spawn (for now)
- added GError argument to utils_spawn_* functions
What does it do on windows? We may add getLastError and create a GError from its content (have to see what exactly is a GError :)
- made helper functions in win32.c static
- some little coding style changes, just cosmetics
Questions: You told win32_spawn() always creates processes asynchronous? If so, it should be ok to use it for g_spawn_sync and g_spawn_async calls, right? I must admit I didn't test the code much, yet.
on Windows? They don't work in a reliable way, that's the problem. But the same base code can be used for both functions yes. That's what does glib too as far as I can see.
Do you think it's possible to create g_spawn_async_with_pipes() on Windows?
It is possible yes, I use a similar solution already to fetch the content. It uses pipes for the stdin/out/err.
We use the _with_pipes variant for the whole Build system code as well as for the Custom commands and Find in Files search. This doesn't need to be exported to the plugin API but it would be really useful in Geany itself. But only if you like to and if you have time for it.
Yes, I can do it as well and add support for the async versions of the glib spawn functions. I can do it once I had the time to look closer to the existing geany code and how it works :)
The same spawn_with_pipes may be used to have a shell on windows, but my little tests are not yet ready for public reviews.
Cheers,
On Sat, 23 Feb 2008 18:57:41 +0100, "Pierre Joye" pierre.php@gmail.com wrote:
Hi,
Changes:
- renamed geany_w32_spawn_sync in win32_spawn
- added utils_spawn_async() which calls g_spawn_async() on non-Win32
systems, else it calls win32_spawn (for now)
- added GError argument to utils_spawn_* functions
What does it do on windows? We may add getLastError and create a GError from its content (have to see what exactly is a GError :)
At the moment, it only creates a GError object with a general error message. But maybe we could indeed use the GetLastError() function. I guess we have to use FormatMessage to get an error string from it, right? I had a short look and at the moment I'm not sure how to use it. What exactly is a LPTSTR and can it be converted into a char* ? Anyway, using the GError system has two advantages: - we don't have to rewrite existing code which relies on that the given error argument is set if an error occurred - we can use the already existing way of error reporting
- made helper functions in win32.c static
- some little coding style changes, just cosmetics
Questions: You told win32_spawn() always creates processes asynchronous? If so, it should be ok to use it for g_spawn_sync and g_spawn_async calls, right? I must admit I didn't test the code much, yet.
on Windows? They don't work in a reliable way, that's the problem. But
I'm a little confused. The current code works synchronous with the calling process(geany)? This is what I'm experiencing (at least I think so, hard to say on an emulated Windows in VirtualBox :D). But I thought you have said on Windows spawned processes are asynchronous?
Do you think it's possible to create g_spawn_async_with_pipes() on Windows?
It is possible yes, I use a similar solution already to fetch the content. It uses pipes for the stdin/out/err.
If it would require too much work, too mch code or isn't realisable at all(for whatever reasion), it might be ok to fake the pipes by running the process, when it is finished we grab the output on stdout and feed it completely to the pipe to which is Geany listing. This would cause Geany's GUI to freeze while the command is running but at least it would work.
Regards, Enrico
On Sun, Feb 24, 2008 at 3:54 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
But maybe we could indeed use the GetLastError() function. I guess we have to use FormatMessage to get an error string from it, right?
See also: http://tinyurl.com/yul784
- Jeff
On Sun, 24 Feb 2008 07:03:49 -0600, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Sun, Feb 24, 2008 at 3:54 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
But maybe we could indeed use the GetLastError() function. I guess we have to use FormatMessage to get an error string from it, right?
See also: http://tinyurl.com/yul784
Thanks Jeff, didn't know that function. Things can be so easy...:D.
Regards, Enrico
On Wed, 20 Feb 2008 16:42:19 +0100, "Pierre Joye" pierre.php@gmail.com wrote:
Hi,
Also added $(MAKE) variable for mingw Makefiles, instead of statically defined "make". My install has mingw32- as prefix for all gnu cmd and only some exists without.
I added this but kept the default value at "make". But it can be easily overwritten in localwin32.mk.
Regards, Enrico