- Better build system (maybe CMake)The current method we use is to supply two cbp files, one for Windows and the other one for Linux.
Hello, tomolt, I see this is your first post in our forum, welcome!Thanks, ollydbg, but I'm not exactly new to C::B, only the forum (I'm using C::B for about one year now!). ;)
You did a good job!!! Keep going, and ask questions about C::B here if you need some help.
The current method we use is to supply two cbp files, one for Windows and the other one for Linux.I wasn't exactly sure how to set the build system up anyways, CMake was just the first good system that came into my mind. :)
src/CloneDialog.cpp | 2 +-
src/CommitAllDialog.cpp | 2 +-
src/CommitDialog.cpp | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/CloneDialog.cpp b/src/CloneDialog.cpp
index 3404cf8..afcd2a1 100644
--- a/src/CloneDialog.cpp
+++ b/src/CloneDialog.cpp
@@ -1,6 +1,6 @@
#include "CloneDialog.h"
-CloneDialog::CloneDialog(wxWindow *parent) : wxDialog(parent, ID_CLOD, _T("Clone repository"))
+CloneDialog::CloneDialog(wxWindow *parent) : wxDialog(parent, ID_CLOD, wxString(_T("Clone repository")))
{
wxBoxSizer *clodSizer = new wxBoxSizer(wxVERTICAL);
SetSizer(clodSizer);
diff --git a/src/CommitAllDialog.cpp b/src/CommitAllDialog.cpp
index 12f02c5..7c5556e 100644
--- a/src/CommitAllDialog.cpp
+++ b/src/CommitAllDialog.cpp
@@ -1,6 +1,6 @@
#include "CommitAllDialog.h"
-CommitAllDialog::CommitAllDialog(wxWindow *parent) : wxDialog(parent, ID_COAD, _T("Commit all"))
+CommitAllDialog::CommitAllDialog(wxWindow *parent) : wxDialog(parent, ID_COAD, wxString(_T("Commit all")))
{
wxBoxSizer *coadSizer = new wxBoxSizer(wxVERTICAL);
SetSizer(coadSizer);
diff --git a/src/CommitDialog.cpp b/src/CommitDialog.cpp
index fbcb888..e42d2d6 100644
--- a/src/CommitDialog.cpp
+++ b/src/CommitDialog.cpp
@@ -4,7 +4,7 @@
#include <cbproject.h>
#include <projectfile.h>
-CommitDialog::CommitDialog(wxWindow *parent) : wxDialog(parent, ID_COMD, _T("Commit"))
+CommitDialog::CommitDialog(wxWindow *parent) : wxDialog(parent, ID_COMD, wxString(_T("Commit")))
{
ProjectManager *ProjMan = Manager::Get()->GetProjectManager();
filenames.push_back(ProjMan->GetActiveProject()->GetFilename());
I'm not too keen on autotools, so I will probably go with codeblocks projects! :)As far as I'm concerned this is the only build system that plays well with distro packages, and that is why I'm using it.
What we need is an automatable console-only program that builds C::B projects! Something like "codeblocks-build GitBlocks.cbp -tdefault"! :)I'm not too keen on autotools, so I will probably go with codeblocks projects! :)As far as I'm concerned this is the only build system that plays well with distro packages, and that is why I'm using it.
Also I'm using it in a modern and minimal way (only two files related to autotools in the whole repo).
It won't help much with the integration with linux distros.I meant prebuild packages. Of course it won't work for source distribution.
this could be a candidate for a contrib plugin in our repo in the end, but then it has to be build also with autotools, like all our other plugins. So I would suggest to try to play the game of the contrib plugins.Okay, I'll try to switch to autotools in the near future, but I first have to learn it.
Well, yes, there WAS a build script by stahta01 for Windows, but I had to take it out because I am now using autotools, which works fine on my Arch Linux box, and also *should* work fine on Windows, but I can't test it! :(
Well, yes, there WAS a build script by stahta01 for Windows, but I had to take it out because I am now using autotools, which works fine on my Arch Linux box, and also *should* work fine on Windows, but I can't test it! :(
Maybe this is not a question for you, but I see little documentation / articles about using autotools on a windows machine. Most documentation for windows is to build plug-ins using Code::Blocks itself, and many other plug-ins appeared to provide cbp files for different wxWidgets versions and architectures along with autotools files. They can co-exist, and it seems there is some kind of naming conventions of cbp files to distinguish the environment each cbp file support. I wonder what the guideline/convention is in this CB plug-in development community. And BTW setting up autotools in pure windows environment can be unpleasant process, you might need to use MSYS or cygwin. At the end, setting up cbp might be much easier, faster and maintainable. (Just that it is not for non-interactive-building.)
Anyway, I managed to get GitBlocks compiled using my own cbp file on windows, and now seeing crashes when invoking any of GitBlocks commands from top menu. (GUI operations appeared to be working, menu items show up, some dialogue box for user input shows up, but then entire C::B stops.) Haven't had a chance to narrow down the root cause yet.
If you want I can re-create or find the cbp file for windows.
./bootstrap
./configure
make -f Makefile.in
make -f Makefile.in
make -f Makefile
I suppose you have to build the plugin yourself.
I suppose you have to build the plugin yourself.
Is there a complete and total For Dummies on how to accomplish that? (Sorry, I'm new to CodeBlocks and its plugins, and as described I couldn't find any install info in readme/install/makefiles found in the plugin package, and I haven't had to research how to build plugins before install for other IDE tools)
Fetching status ...
git status
Fetching from origin ...
cmd.exe /C "git fetch origin"
Fetching log ...
git log --pretty=format:%h%x09%an%x09%ad%x09%s
stahta01, just now compile plugin from your repo, its not work.CodeFetching status ...
git status
Fetching from origin ...
cmd.exe /C "git fetch origin"
Fetching log ...
git log --pretty=format:%h%x09%an%x09%ad%x09%s
Windows 8 x64
Any plans to embed this plugin better in the UI instead of putting everything under a menu ?I am not sure if this project is still active. It has also quite some serious bugs, some of them I've fixed already, but its not prime-time yet.
I can't imagine it could be that much of a time saver compared to just launching the commit from the Explorer integration of installed SVN/Git software.Perfectly true. Unless you provide features like flat mode that need good additional programming before launching the commands.
Yes, and you forget that other platforms don't have Tortoise, and looking at a diff of a single file would be a lot more practical when it's open in the IDE...I can't imagine it could be that much of a time saver compared to just launching the commit from the Explorer integration of installed SVN/Git software.Perfectly true. Unless you provide features like flat mode that need good additional programming before launching the commands.
Yes, and you forget that other platforms don't have Tortoise, and looking at a diff of a single file would be a lot more practical when it's open in the IDE...Well first of all there is not only Tortoise (which I don't like at all, btw) and for other platforms plenty of different really good tools are available, too. It should be clear that we will never reach the richness of an application created only for version control. I use SmartSVN which runs on all platforms and I am very happy with it. I also see that many of the features are rather complex and have been developed in decades by the (SmartSVN) team. So I think we should not try to re-invent the wheel because we can only loose.
It should be clear that we will never reach the richness of an application created only for version control.I agree, I don't need all those features of branching, rebasing etc, only features that the existing tools can't deliver where it makes sense in regards to Code::Blocks integration. IMHO that's why I asked the question in the first place, to actually get a diff from a file that I can click in C::B without having to go to some external tool/browser, find the file and have the diff open outside of C::B...
All in all I think the approach to integfreate VCS in the FileManager plugin would be my favourite and dmoore has started it already some time ago. That doesn't mean I don't like Git/SVN/...only plugins but the more we get of these trying to pump in all features and failing the more I believe we should make it really simple in the first place but considering the most important features from the beginning.
Looks very decent, there is even a branch that implemented auto-detection of the type of file.I wasn't aware of that one. Who did it? Can you post a link?
I agree, I don't need all those features of branching, rebasing etc, only features that the existing tools can't deliver where it makes sense in regards to Code::Blocks integration. IMHO that's why I asked the question in the first place, to actually get a diff from a file that I can click in C::B without having to go to some external tool/browser, find the file and have the diff open outside of C::B...I've setup a tool that opens my diff program with the currently selected file and if there are changes it shows them. It also goes to the correct line:)
I agree, I don't need all those features of branching, rebasing etc, only features that the existing tools can't deliver where it makes sense in regards to Code::Blocks integration. IMHO that's why I asked the question in the first place, to actually get a diff from a file that I can click in C::B without having to go to some external tool/browser, find the file and have the diff open outside of C::B...I've setup a tool that opens my diff program with the currently selected file and if there are changes it shows them. It also goes to the correct line:)
I have also commands for git gui blame and gitk. They are pretty handy.
https://github.com/danselmi/cbDiffOK. I knew that but forgot. There is another one here:
Does it start C::B when you do a git gui blame ? Maybe a nice howto or some notes on what you've configured? Helps others figuring out what to do to setup this...No it doesn't start C::B, I'm using external diff tool (diffuse to be precise).
Oh, I was thinking that https://github.com/ywx/cbDiff was the original one?Nope. That was a fork already. The original was a large attachment to the first post which was removed some times back - unnoticed, during a forum clean-up. That's why we always say, don't post important files in the forums, they will get lost for sure some day. But I think GeO never created a repo for his work, unfortunately.
So it means I merged the 2 existing branches.Yes, looks like that. Good to know... not so nice is that we have 3 unsync'd projects now.
||=== Build: default in GitBlocks (compiler: GNU GCC Compiler) ===|
/usr/include/wx-3.0/wx/dialog.h fatal error: wx/toplevel.h: No such file or directory
||=== Build failed: 1 error(s), 0 warning(s) (0 minute(s), 7 second(s)) ===|