I would like to know how you're building from CVS. You just use the project file provided or do you tune it before building (like removing debugging information parameter, adding stripping, optimizations, ...)?
I would also like to know which plugins you're bundling with your build (contrib plugins).
BTW did you saw that post about w98 problems with our builds?There is no problem with the build. The issue is about SHGetFolderPath which is available on any reasonably up-to date Windows system.
BTW did you saw that post about w98 problems with our builds?There is no problem with the build. The issue is about SHGetFolderPath which is available on any reasonably up-to date Windows system.
Windows98 SE, ME, 2000, and NT4 support it out of the box. Only Windows98 and 95 do not, they require at least Internet Explorer 5. I daresay that these are no impossible requirements ;)
HelloCould you, just like Ceniza does, put a link to your SVN binaries in your signature? :)
I have just uploaded the latest svn head build.
Enjoy.
HelloCould you, just like Ceniza does, put a link to your SVN binaries in your signature? :)
I have just uploaded the latest svn head build.
Enjoy.
Updated to rev1447.
New Sdk v1.6, many bugfixes (including wxWidgets), optimizations on startup (got much faster). This is really a big step.
Enjoy :-)
Itsn't more easy to check out from SVN?
The compiled SDK .a and header files makes more sense in official releases.
would you be so kind and add SHFolder(before Shell32) to the link libraries of the sdk target for your builds - then Codeblocks could be used on W98 again.
would you be so kind and add SHFolder(before Shell32) to the link libraries of the sdk target for your builds - then Codeblocks could be used on W98 again.
Hello Revy
I have just recompiled CB with this lib, unfortunatelly, i dont have 98, can you test it pls?
I ll upload (rev1450) in a couple of minutes.
Thx
would you be so kind and add SHFolder(before Shell32) to the link libraries of the sdk target for your builds - then Codeblocks could be used on W98 again.
Hello Revy
I have just recompiled CB with this lib, unfortunatelly, i dont have 98, can you test it pls?
I ll upload (rev1450) in a couple of minutes.
Thx
I guess I will just have to upgrade to W2k/XP and use MS Visual C++ again.
I'm a bit sad atm, because Code::Blocks is meant to be a portable IDE and can't even run on different Win32 platforms.
And the worst is, I'm absolutly sure the usage of W98 is higher than the usage of Linux.
Bye
A sad Revy
Code// TODO (mandrav#1#): Check windows version and substitute cmd.exe with command.com if needed.
cmd->command = _T("cmd /c ") + cmd->command;
It shouldn't be that hard to change it, if there is a possibility to find which command to use (command or cmd) then it is very easy..
if(wxGetOsVersion() == wxWIN95)
cmd->command = _T("command /c ") + cmd->command;
else
cmd->command = _T("cmd /c ") + cmd->command;
Quote from: C::B sourcesCode// TODO (mandrav#1#): Check windows version and substitute cmd.exe with command.com if needed.
cmd->command = _T("cmd /c ") + cmd->command;
// special shell used only for build commands
if (!cmd->isRun)
{
#ifndef __WXMSW__
// run the command in a shell, so backtick'd expressions can be evaluated
cmd->command = GetConsoleShell() + _T(" '") + cmd->command + _T("'");
#else
// TODO (mandrav#1#): Check windows version and substitute cmd.exe with command.com if needed.
cmd->command = _T("cmd /c ") + cmd->command;
#endif
}#ifndef __WXMSW__
// special shell used only for build commands
if (!cmd->isRun)
{
// run the command in a shell, so backtick'd expressions can be evaluated
cmd->command = GetConsoleShell() + _T(" '") + cmd->command + _T("'");
}
#endif
I saw that change a while back, and I was wondering: Is there any particular reason "cmd /c " is prepended at all? Shouldn't it "just work" if you that wasn't done?
I see that according to the comments the reason a shell is prepended is to allow backticked expressions to execute, but I'm not aware of any windows version where that works (it's different for *nix of course). It certainly doesn't work in my win2000 cmd.exe...
Yes, you 're right. The comment does not explain the reasoning for this change.
This was added to allow builtin shell commands to be used in pre-build and post-build steps, i.e. cp, del, etc. These do not work if not invoked within a shell.
I think this code should have the exact same effect, except it on win9x where it actually works now ;):It doesn't have the same effect. it has to be done without quotes, else it will not compile (on XP) (with I mean with 'not compile' is that the command is not correct when I want to compile a file with the "new" version. The compiler plugin compiles correctly):Code#ifndef __WXMSW__
// special shell used only for build commands
if (!cmd->isRun)
{
// run the command in a shell, so backtick'd expressions can be evaluated
cmd->command = GetConsoleShell() + _T(" '") + cmd->command + _T("'");
}
#endif
#ifndef __WXMSW__
// run the command in a shell, so backtick'd expressions can be evaluated
cmd->command = GetConsoleShell() + _T(" '") + cmd->command + _T("'");
#else
cmd->command = GetConsoleShell() + cmd->command;
#endif
Yes, you 're right. The comment does not explain the reasoning for this change.
This was added to allow builtin shell commands to be used in pre-build and post-build steps, i.e. cp, del, etc. These do not work if not invoked within a shell.
Ah, I understand. But I think you meant copy. And I should mention cp has worked just fine for me so far :).
But still, wouldn't it be a cleaner solution to have GetConsoleShell() return the proper command? That way this code can be un-#ifdef'd, and if you put the code to detect cmd.exe/command.com in there it'll probably be easier to cache. You could even make it a setting like in the *nix version. Just enable that textbox in the compiler options, and autodetect only on first run.
Then the user could even change it if he prefers sh.exe for example ;). (though sh.exe would break copy again, but that's the user's choice: he gets backticks and other goodies in return. Besides, he could always create a copy script/alias for cp)
I think this code should have the exact same effect, except it on win9x where it actually works now ;):It doesn't have the same effect. it has to be done without quotes, else it will not compile (on XP) (with I mean with 'not compile' is that the command is not correct when I want to compile a file with the "new" version. The compiler plugin compiles correctly):Code#ifndef __WXMSW__
// special shell used only for build commands
if (!cmd->isRun)
{
// run the command in a shell, so backtick'd expressions can be evaluated
cmd->command = GetConsoleShell() + _T(" '") + cmd->command + _T("'");
}
#endif
I didn't re-use GetConsoleShell() because it was initially created for non-windows installations. This has the side-effect that everyone has it now in their configuration as "/bin/sh". Do you see the problem?
Eventually, we will use GetConsoleShell() but we 'll have to check its value too...
EDIT: and mispunt is right about the quotes. I forgot to mention it...
QuoteEDIT: and mispunt is right about the quotes. I forgot to mention it...
See above
I guess I will just have to upgrade to W2k/XP and use MS Visual C++ again.
I'm a bit sad atm, because Code::Blocks is meant to be a portable IDE and can't even run on different Win32 platforms.
And the worst is, I'm absolutly sure the usage of W98 is higher than the usage of Linux.
Bye
A sad RevyQuote from: C::B sourcesCode// TODO (mandrav#1#): Check windows version and substitute cmd.exe with command.com if needed.
cmd->command = _T("cmd /c ") + cmd->command;
Revvy, you 're free to go whichever way you want but judging a program while it is still being developed is plain wrong.
You want to use the SVN-HEAD version. That's just fine. But if things don't work for you as expected (yet), you shouldn't complain about it. We 're working hard on this project and trying to make everybody happy. But things need to be coded to work. Code doesn't just write itself. So if I haven't had the time yet to fix this, it doesn't mean I never will.
If you want this to work now, provide a patch.
I don't work for you, nor any of the other developers. We do this on our free time and you have to respect it. If you don't like C::B, you 're free not to use it. But you don't have the right to demand from anyone here to work on your schedule.
You see Revvy, open source doesn't mean "free workers at your disposal". You got things all wrong...
If you don't like C::B, you 're free not to use it.I do like C::B, but I can't use it(at least the cvs builds).
Sorry, but where did I wrote that anyone of the develpers work for me?
I guess I will just have to upgrade to W2k/XP and use MS Visual C++ again.
I'm a bit sad atm, because Code::Blocks is meant to be a portable IDE and can't even run on different Win32 platforms.
And the worst is, I'm absolutly sure the usage of W98 is higher than the usage of Linux.
Bye
A sad Revy
QuoteIf you don't like C::B, you 're free not to use it.I do like C::B, but I can't use it(at least the cvs builds).
For a person like me who is not so into C::B developement, it looks like C::B is only meant for W2k and above - first the SHFolder problem now this problem.
And there I think is a big problem - on W2k+ everyone can use the fancy MS IDE, which would mean as a consequence that C::B will be mainly used on Linux and of course from some W2k+ <> Linux Crossplatform devs.
You want to use the SVN-HEAD version. That's just fine. But if things don't work for you as expected (yet), you shouldn't complain about it. We 're working hard on this project and trying to make everybody happy. But things need to be coded to work. Code doesn't just write itself. So if I haven't had the time yet to fix this, it doesn't mean I never will.
Do you understand now why I said it needs some time to be correctly fixed/implemented?hmm. yes I understand, the problem is that I can't find the documentation for GetConsoleShell()..
:( blahblahblahblahblah
:x blahblahblahblahblah!!
:o blahblahblah!?
Quote from: Revvy:( blahblahblahblahblahQuote from: mandrav:x blahblahblahblahblah!!Quote from: Revvy:o blahblahblah!?
:shock: Guys, please keep it clean, the thread's getting too noisy. Anyway...
Revvy, look, I don't think any of us developers has Win98 to test and stuff, we appreciate your effort to make it work on that platform. The reason we can't release a workable version *right now* is that there are still many bugs to tackle. It's just about being patient and having to bear with an open source product *still* in beta. But since the feature is already being implemented, there's nothing to worry about, right? And Yiannis, please try to be a little softer the next time (just a suggestion).
AAAAAAAAAAAnyway... :) where were we?
I personally test it under XP/SP2 and Windows 98SEThis is really nice to hear, thank you very much.
"Why don't you make it work on Win98 so I can work with it? I will go to MSVC then."
And Yiannis, please try to be a little softer the next time (just a suggestion).I don't think he was entirely unjustified in his reply, although it was not Revvy's fault alone - it is a general attitude problem which is slowly evolving. Revvy was just unlucky to be the person getting it today.
and while they're typing their flames, they don't write code ;)
Revvy, look, I don't think any of us developers has Win98 to test and stuff, we appreciate your effort to make it work on that platform. The reason we can't release a workable version *right now* is that there are still many bugs to tackle. It's just about being patient and having to bear with an open source product *still* in beta. But since the feature is already being implemented, there's nothing to worry about, right?
And Yiannis, please try to be a little softer the next time (just a suggestion).
Mispunt is referring to using GetConsoleShell() under both platforms. For windows it would be cmd /c arguments while for linux it would be /bin/sh 'arguments' (notice the quotes).
Your solution is to revert to the previous way, which does not allow for builtin shell commands (i.e. for windows, no command shell).
s010625@svstud:~/tmp$ ls -l
total 8
-rw------- 1 s010625 student 0 Dec 6 17:48 testfile
s010625@svstud:~/tmp$ sh -c 'ls -l'
total 8
-rw------- 1 s010625 student 0 Dec 6 17:48 testfile
s010625@svstud:~/tmp$ sh -c "ls -l"
total 8
-rw------- 1 s010625 student 0 Dec 6 17:48 testfile
s010625@svstud:~/tmp$ cat /proc/version
Linux version 2.6.12-1.1372_FC3smp (bhcompile@tweety.build.redhat.com) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 SMP Fri Jul 15 01:30:03 EDT 2005
s010625@svstud:~$ sh --version
GNU bash, version 3.00.14(1)-release (i386-redhat-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
Frits@S010625:/d/tmp$ ls -l
total 2
-rw-r--r-- 1 Frits Administ 73 Dec 6 17:49 testfile
Frits@S010625:/d/tmp$ cat testfile
total 0
-rw-r--r-- 1 Frits Administ 0 Dec 6 17:49 testfile
Frits@S010625:/d/tmp$ ls -l
total 2
-rw-r--r-- 1 Frits Administ 73 Dec 6 17:49 testfile
Frits@S010625:/d/tmp$ sh -c 'ls -l'
total 2
-rw-r--r-- 1 Frits Administ 73 Dec 6 17:49 testfile
Frits@S010625:/d/tmp$ sh -c "ls -l"
total 2
-rw-r--r-- 1 Frits Administ 73 Dec 6 17:49 testfile
Frits@S010625:/d/tmp$ sh --version
GNU bash, version 2.04.0(1)-release (i686-pc-msys)
Copyright 1999 Free Software Foundation, Inc.
Anyway, we removed cmd.exe completely (i.e. reverted the way it was before). It seems it caused other problems (http://forums.codeblocks.org/index.php?topic=1553.new#new) too.
So, Revvy, when Therion creates another snapshot your problem will be gone :).
rev1534 uploaded
Check this out: http://forums.codeblocks.org/index.php?topic=1674.0
rev 1534 seems broken (and I updated - built and can't compile anymore):(
Btw, i've just uploaded r1578, it's still ansi :( ill try to figure out how build the unicode asap.
merry x-mas for you all,Feliz Natal para vôce. Merry Christmas for you all.
Michael: Pra voce tambem :-) (i.e. "For you too") Where are you from? Brazilian too?
yes, it happens with other files also, for example with some scintilla cb files, see another post. Bug has already been filed on SF, hope it will get fixed soon. In antoher report it was stated that the file might contain some charactrs that don't translate well in unicode (as far as I understood).
Lieven
Hello all, happy new year :-)Do these happen to be non-Unicode files with a charset different from ISO 8859-1?
Uploaded rev 1644 unicode.
There is a strange bug in it, some of my source files doesn't open on editor, i mean, they are opened but the editor remains empty...
Hello all, happy new year :-)Do these happen to be non-Unicode files with a charset different from ISO 8859-1?
Uploaded rev 1644 unicode.
There is a strange bug in it, some of my source files doesn't open on editor, i mean, they are opened but the editor remains empty...
I heard similar things before, although I am not able to reproduce it. It seems that wxScintilla has no problems opening UTF-8 files, but some non-US/non-Euro charsets seem to fail...?
sdk\wxscintilla\src\scintilla\src\editor.cxx will fail because it is not UTF8. Code::Blocks doesn't have support for opening files that are not UTF8Sam, this is not true. Code::Blocks does certainly support opening non-Unicode files. What drives you to make such a hilarious statement?
thomas, you have to realize that ASCII files are also UTF8.Incorrect/inaccurate information. This is only true (coincidally) for character codes below 127.
$ cat müll.cpp
// ▒1 sch▒ner M▒ll mit vielen Umlauten, so da▒ auch Sam sehen kann,
$ hexdump müll.cpp
0000000 2f2f a720 2031 6373 f668 656e 2072 fc4d
0000010 6c6c 6d20 7469 7620 6569 656c 206e 6d55
0000020 616c 7475 6e65 202c 6f73 6420 df61 6120
0000030 6375 2068 6153 206d 6573 6568 206e 616b
0000040 6e6e 0d2c 2f0a 202f 2020 7720 7361 6620
0000050 72fc 6520 6e69 fc20 6c62 7265 202c 62fc
0000060 7265 6c66 73fc 6973 6567 2072 6e55 6973
0000070 6e6e 6420 7361 6920 7473 2e2e 002e
000007d