Author Topic: FileManager: Version Control Browsing  (Read 13167 times)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
FileManager: Version Control Browsing
« on: January 30, 2015, 04:30:27 am »
20 hours of my life I'm not getting back... not sure whether it's useful or not but I've been building up the infrastructure to let users browse the commit history of their version control system. For now, It only works properly with git and is very bare boned.

Apply the attached path to C::B sources, build C::B + file manager plugin and run C::B. Flip to the "files" tab, enable git decorators (right click on an item in the tab then look under settings in the popup):



Then navigate to a folder that's under Git version control. That will show a wxChoice box, click it and choose "Select Commit"



Which will let you browse your commits.



Select one and click on the "Use Selected Commit" button and you should be able to browse the tree for that commit and open the files in C::B (they are saved to a temp folder)

Obviously still needs a ton of work and has a bunch of silly bugs. The intent is to be able to support browsing of GIT, SVN, HG and BZR (and hopefully then you'll all see how shitty SVN is and we can switch to GIT!!) and do nice things like search and diff views.

See last post for the current patch.
« Last Edit: February 10, 2015, 05:35:29 am by dmoore »

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5177
Re: FileManager: Version Control Browsing
« Reply #1 on: January 30, 2015, 07:24:51 am »
cool, please also add support for svn ;-)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: FileManager: Version Control Browsing
« Reply #2 on: January 31, 2015, 05:21:56 am »
New patch attached supporting both GIT and SVN. This one updates the windows project file (but not the wx3.0 files) but hasn't been tested.  GIT/SVN must be in the system path for the feature to work correctly.
« Last Edit: February 09, 2015, 08:33:15 pm by dmoore »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: FileManager: Version Control Browsing
« Reply #3 on: January 31, 2015, 07:04:21 am »
New patch attached supporting both GIT and SVN.
Very nice... :D
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: FileManager: Version Control Browsing
« Reply #4 on: February 02, 2015, 03:33:36 am »
New patch. Crushes a bunch of bugs and implements browsing for Bazaar and Mercurial. Plan to add support for searching commits by name or revision, viewing diffs etc.

But more generally, having now played around with a few different VCS systems, I think I can see how to integrate support for all of them throughout C::B. So, for example, when you have a file open in an editor that's under a VCS, you will be able to see options to see its VCS status, history, and diffs. The same goes for files in the project tree.
« Last Edit: February 09, 2015, 08:34:13 pm by dmoore »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: FileManager: Version Control Browsing
« Reply #5 on: February 09, 2015, 04:49:39 am »
New patch features searching for a particular commit. (Date ranges don't work properly yet.)

EDIT: Ooops. bad patch. new one cominng soon.
« Last Edit: February 09, 2015, 03:10:19 pm by dmoore »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: FileManager: Version Control Browsing
« Reply #6 on: February 09, 2015, 08:41:37 am »
New patch features searching for a particular commit. (Date ranges don't work properly yet.)
Does it make sense to move this functionality to the project tree sooner or later?

What do you mean by:
But more generally, having now played around with a few different VCS systems, I think I can see how to integrate support for all of them throughout C::B.
?
Does it mean another plugin / the work you do... something else? :-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: FileManager: Version Control Browsing
« Reply #7 on: February 09, 2015, 04:23:42 pm »
Does it make sense to move this functionality to the project tree sooner or later?

Yes. It's reasonably stable now, so as soon as I can. But still need to test on windows and fix the makefiles.

Quote
Does it mean another plugin / the work you do... something else? :-)

Not sure yet. Maybe just a separate VCS plugin, but that will be a little tricky to integrate with a separate file manager plugin. Otherwise a new manager/plugin combination, but I'd prefer not to do that. It will mean refactoring this patch quite a bit to separate out VCS specific code into separate classes.

Updated patch attached.
« Last Edit: February 09, 2015, 08:33:00 pm by dmoore »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: FileManager: Version Control Browsing
« Reply #8 on: February 10, 2015, 05:34:58 am »
Now in SVN. I think I got the makefiles and windows stuff right, but not wx3.0 yet, and probably not PCH/non-PCH.

« Last Edit: February 10, 2015, 05:44:51 am by dmoore »

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5177
Re: FileManager: Version Control Browsing
« Reply #9 on: February 11, 2015, 10:48:24 am »
works nicely.


Some requests ? suggestions ?  (doing this via svn)

- can a history entry be made (now it is available, via the diff against)
- but the diff, when you get it via right click context menu is containing all commits, would be more nice to have only the commits impacting this file
- in the history (diff), select 2 revisions and see the diff between those 2
- some way of instructing that the diff  should be send to meld (instead of the patch diff notation)

Is there a way when in the project tree to end up directly to the integration which is now in the Files tab ? Or as step in between : right click on a file in the project tree, and tell it to go to the corresponding place in the files tree (so no need to search there for the file first) ?

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: FileManager: Version Control Browsing
« Reply #10 on: February 11, 2015, 02:58:19 pm »
Some requests ? suggestions ?  (doing this via svn)

Of course. SVN is the problem child. For example, I still need to figure out how to handle password prompts every time I browse the log  ???

Quote
- can a history entry be made (now it is available, via the diff against)

As in the history of commits? Not sure what you have in mind.

Quote
- but the diff, when you get it via right click context menu is containing all commits, would be more nice to have only the commits impacting this file

Yes, planning to add the feature to specify changes only affecting a certain file in the commit browser dialog and to use that by default for the diff.

Quote
- in the history (diff), select 2 revisions and see the diff between those 2
- some way of instructing that the diff  should be send to meld (instead of the patch diff notation)

Yes, eventually

Quote
Is there a way when in the project tree to end up directly to the integration which is now in the Files tab ? Or as step in between : right click on a file in the project tree, and tell it to go to the corresponding place in the files tree (so no need to search there for the file first) ?

I do plan to integrate something into the project tree, but not sure how extensive that will be just yet. Right now you can right click on a project and open the corresponding directory in the file browser and I could probably do something similar for individual files. The logic is trickier if the repo is say, /projects, the project file is as project/project1/project1.cbp, but the file is /project1/src/module1/module1.cpp.  Should the filemanager set the root to /projects and then expand the subdirectories to show and center on the location of the file? The logic for that is a little tricky because you need to figure out which repo the file is in.

By the way, the show changed files only also makes it easier to find changed files.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: FileManager: Version Control Browsing
« Reply #11 on: February 11, 2015, 05:45:51 pm »
My 2 cents for today...:
1.) I don't understand the "favourites" system: I can setup favourites (that works nice), but how do I access them?
2.) Crash: Whenever I try to set some folder to be the root folder I get a crash pointing to the FileManager plugin.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: FileManager: Version Control Browsing
« Reply #12 on: February 11, 2015, 05:50:53 pm »
2.) Crash: Whenever I try to set some folder to be the root folder I get a crash pointing to the FileManager plugin.
Some more details:
It happens in the marked line:
Updater::~Updater()
{
    if(m_exec_proc)
    {
        m_exec_timer->Stop(); // << crash here!
        delete m_exec_timer;
        m_exec_proc->Detach();
        m_exec_cond->Signal();
        m_exec_mutex->Unlock();
    }
    if(IsRunning())
    {
        m_kill=true;
        Wait();
    }
}

...and m_exec_timer is "0xbaadf00d" -> unallocated.

It happens on folders that are under version control and where the VCS executables are not found (in the debug build I see: "Execution of command XXXX failed...").
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: FileManager: Version Control Browsing
« Reply #13 on: February 11, 2015, 05:58:09 pm »
...and m_exec_timer is "0xbaadf00d" -> unallocated.
Naaah... fixed in SVN.

You'd better remember to ALWAYS initialise pointer variables in the constructor in the future... ;-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: FileManager: Version Control Browsing
« Reply #14 on: February 11, 2015, 06:20:09 pm »
Naaah... fixed in SVN.
...but I'll give you another one: If in debug mode, a missing VCS executable will raise a wxExecute error dialog that freezes C::B completely.

My suggestion:
If you handle the wxExecute result yourself (which seems to be the case), use wxLogNull to avoid such freezes, like:

{
  wxLogNull ln;
  h_result = wxExecute(...)
}

To handle all the different wxExecute calls across the plugin (I counted at least 15) you should put them into one place/method which you call with a parameter what command to call exactly.

Maybe you share my thoughts...?!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: FileManager: Version Control Browsing
« Reply #15 on: February 11, 2015, 07:05:40 pm »
My 2 cents for today...:
1.) I don't understand the "favourites" system: I can setup favourites (that works nice), but how do I access them?

The first items in the ComboBox that shows the current path will be populated with your favorites. (It's a little clunky, I admit.)

...and m_exec_timer is "0xbaadf00d" -> unallocated.
Naaah... fixed in SVN.

You'd better remember to ALWAYS initialise pointer variables in the constructor in the future... ;-)

Well, that's embarrassing.

...but I'll give you another one: If in debug mode, a missing VCS executable will raise a wxExecute error dialog that freezes C::B completely.

Thanks for the tip. I had already refactored all of the wxExecute calls into a single place for the threaded parts and will do the same for the remaining calls.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: FileManager: Version Control Browsing
« Reply #16 on: February 11, 2015, 08:56:54 pm »
The first items in the ComboBox that shows the current path will be populated with your favorites. (It's a little clunky, I admit.)
Aaah - dammed - I missed it. :-/ But if you know it makes sense. Maybe a "hint" like a label would help to discover...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline blauzahn

  • Multiple posting newcomer
  • *
  • Posts: 101
Re: FileManager: Version Control Browsing
« Reply #17 on: February 12, 2015, 10:21:35 pm »
Hi, nice idea but...the recent svn-changes are breaking my build :-(

I use Ubuntu 14.04 and compile the trunk via makefile quite regularly. That stopped 3 days ago.
It looks like this bug has been introduced by svn 10107 since I have a working 10106.

Compiling cb stops with:

Code: [Select]
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../../../../trunk/src/plugins/contrib/FileManager -I../../../../src/include -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../trunk/src/include -I../../../../../trunk/src/sdk/wxscintilla/include -I../../../../../trunk/src/include/mozilla_chardet -I../../../../../trunk/src/include/mozilla_chardet/mfbt -I../../../../../trunk/src/include/mozilla_chardet/nsprpub/pr/include -I../../../../../trunk/src/include/mozilla_chardet/xpcom -I../../../../../trunk/src/include/mozilla_chardet/xpcom/base -I../../../../../trunk/src/include/mozilla_chardet/xpcom/glue -ansi -DTIXML_USE_STL -Wno-unused-local-typedefs -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -D__FAM__ -MT FileExplorerUpdater.lo -MD -MP -MF .deps/FileExplorerUpdater.Tpo -c ../../../../../trunk/src/plugins/contrib/FileManager/FileExplorerUpdater.cpp  -fPIC -DPIC -o .libs/FileExplorerUpdater.o
In file included from ../../../../../trunk/src/plugins/contrib/FileManager/FileExplorerUpdater.cpp:9:0:
../../../../../trunk/src/plugins/contrib/FileManager/se_globals.h:10:17: fatal error: ../../../../src/include/sdk.h: No such file or directory
 #include <sdk.h>
                 ^
compilation terminated.
Preprocessed source stored into /tmp/ccirly8F.out file, please attach this to your bugreport.
make[4]: *** [FileExplorerUpdater.lo] Error 1


The file sdk.h exists in:

Code: [Select]
codeblocks/trunk/src/plugins/contrib/FileManager$ ls -l ../../../include/sdk.h
-rw-r--r-- 1 user user 457 Apr  2  2013 ../../../include/sdk.h

I always build cb in a directory named build that is parallel to the trunk directory. The plugins up to FileManager compile and the
file sdk.h.gch has been written as usual.

Can you fix this, please? Thank you!



Btw: A cppcheck over the plugin files yields several issues. A few of those might be of a help:

Code: [Select]
cppcheck --verbose --enable=all *.h *.cpp

Code: [Select]
[FileExplorerUpdater.h:44]: (warning) Member variable 'Updater::m_exec_cond' is not initialized in the constructor.

Is there a reason why you put initializations, if any, into the body instead of the initializer list?

Code: [Select]
[FileExplorerUpdater.cpp:1410]: (error) Uninitialized variable: hg_not_done

Code: [Select]
  bool hg_not_done;
  if (m_repo_type == _T("Hg"))
  {
      long last;
      if (m_last_commit_retrieved.ToLong(&last))
          if (last > 0)
              hg_not_done = true;
  }
  if (hg_not_done)
      m_retrieved_all = false;

This is definitely undefined behaviour.

Code: [Select]
[FileExplorer.cpp:1340] -> [FileExplorer.cpp:1340]: (style) Finding
  the same expression on both sides of an operator
  is suspicious and might indicate a cut and paste
  or logic error. Please examine this code carefully to determine if it is correct.

Code: [Select]
if(!wxFileName::DirExists(mkd) &&!wxFileName::DirExists(mkd))

To me this looks being unintended.

Code: [Select]
[directorymonitor.cpp:621]: (warning) Possible leak in public function.
  The pointer 'm_monitorthread' is not deallocated before it is allocated.

Code: [Select]
bool wxDirectoryMonitor::Start()
{
    m_monitorthread=new DirMonitorThread(this, m_uri, false, false, m_eventfilter, 100);
    m_monitorthread->Create();
    m_monitorthread->Run();
    return true;
}

Since Start is a public method, and m_monitorthread is a naked pointer this is not safe.


Thanks!


Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: FileManager: Version Control Browsing
« Reply #18 on: February 12, 2015, 11:27:57 pm »
Thanks for all of the fixes. A few oopses in there :)  :-[

Maybe I'm being dense but I'm not sure what the problem here is

I use Ubuntu 14.04 and compile the trunk via makefile quite regularly. That stopped 3 days ago.
It looks like this bug has been introduced by svn 10107 since I have a working 10106.

Compiling cb stops with:

Code: [Select]
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../../../../trunk/src/plugins/contrib/FileManager -I../../../../src/include -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../trunk/src/include -I../../../../../trunk/src/sdk/wxscintilla/include -I../../../../../trunk/src/include/mozilla_chardet -I../../../../../trunk/src/include/mozilla_chardet/mfbt -I../../../../../trunk/src/include/mozilla_chardet/nsprpub/pr/include -I../../../../../trunk/src/include/mozilla_chardet/xpcom -I../../../../../trunk/src/include/mozilla_chardet/xpcom/base -I../../../../../trunk/src/include/mozilla_chardet/xpcom/glue -ansi -DTIXML_USE_STL -Wno-unused-local-typedefs -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -D__FAM__ -MT FileExplorerUpdater.lo -MD -MP -MF .deps/FileExplorerUpdater.Tpo -c ../../../../../trunk/src/plugins/contrib/FileManager/FileExplorerUpdater.cpp  -fPIC -DPIC -o .libs/FileExplorerUpdater.o
In file included from ../../../../../trunk/src/plugins/contrib/FileManager/FileExplorerUpdater.cpp:9:0:
../../../../../trunk/src/plugins/contrib/FileManager/se_globals.h:10:17: fatal error: ../../../../src/include/sdk.h: No such file or directory
 #include <sdk.h>
                 ^
compilation terminated.
Preprocessed source stored into /tmp/ccirly8F.out file, please attach this to your bugreport.
make[4]: *** [FileExplorerUpdater.lo] Error 1


The file sdk.h exists in:

Code: [Select]
codeblocks/trunk/src/plugins/contrib/FileManager$ ls -l ../../../include/sdk.h
-rw-r--r-- 1 user user 457 Apr  2  2013 ../../../include/sdk.h

I always build cb in a directory named build that is parallel to the trunk directory. The plugins up to FileManager compile and the
file sdk.h.gch has been written as usual.

Comparing the makefiles, it's really not obvious to me what's different.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: FileManager: Version Control Browsing
« Reply #19 on: February 12, 2015, 11:32:32 pm »
And looking at the makefile diff, I struggle to see how anything changed there can be the cause:

http://sourceforge.net/p/codeblocks/code/10107/tree//trunk/src/plugins/contrib/FileManager/Makefile.am?diff=51421f1dc431436b6eb31d56:10106

Are you sure there isn't some sort of corruption of the FileManager sources?
« Last Edit: February 13, 2015, 05:49:36 am by dmoore »

Offline blauzahn

  • Multiple posting newcomer
  • *
  • Posts: 101
Re: FileManager: Version Control Browsing
« Reply #20 on: February 13, 2015, 06:46:21 am »
Quote
Are you sure there isn't some sort of corruption of the FileManager sources?

Yes I am. I downloaded a fresh, vanilla trunk into a newly created empty directory. Same result.

Code: [Select]
mkdir tmp
cd tmp
svn checkout svn://svn.code.sf.net/p/codeblocks/code/trunk
cd trunk
./bootstrap
cd ..
mkdir build
cd build
../trunk/configure --prefix=/usr/local --with-contrib-plugins=all,-NassiShneiderman
make


I do not see either a thing within the Makefile.am diff that may have caused that. What else?

Offline blauzahn

  • Multiple posting newcomer
  • *
  • Posts: 101
Re: FileManager: Version Control Browsing
« Reply #21 on: February 13, 2015, 07:00:01 am »
If I skip the FileManager, the code compiles cleanly:

Code: [Select]
../trunk/configure --prefix=/usr/local --with-contrib-plugins=all,-NassiShneiderman,-FileManager
make -j

The breaking change might also be introduced by a version higher than 10107. Haven't bisected it yet.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11939
    • Travis build status
Re: FileManager: Version Control Browsing
« Reply #22 on: February 13, 2015, 10:43:15 am »
I confirm the breakage. It happens in out-of-tree builds and only if using pch. If I specify --disable-pch it builds fine.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: FileManager: Version Control Browsing
« Reply #23 on: February 13, 2015, 01:08:13 pm »
I have no issues building actual trunk (10118) out of tree, neither with pch, nor without pch.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11939
    • Travis build status
Re: FileManager: Version Control Browsing
« Reply #24 on: February 13, 2015, 01:36:45 pm »
Probably it is something related to newer autotools, because it worked correctly on my CentOS 6 machine, but failed on my Gentoo machine.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: FileManager: Version Control Browsing
« Reply #25 on: February 13, 2015, 08:20:31 pm »
It tested it on my Fedora 21 system and did a build in mock chroots for CentOS 5 to 7 and Fedora 19 to Rawhide (22) (sse: https://copr.fedoraproject.org/coprs/jenslody/codeblocks/build/71814/).
For the record: the copr-builds are all build without pch's and not out of tree.

Offline blauzahn

  • Multiple posting newcomer
  • *
  • Posts: 101
Re: FileManager: Version Control Browsing
« Reply #26 on: February 21, 2015, 08:24:58 am »
I solved the problem I had compiling the plugin starting exactly from version r10107 upwards.

If I change the include-order it works. I changed the first lines of FileExplorerUpdater.cpp from:

Code: [Select]
#include <sdk.h>

#include <wx/sstream.h>
#include <wx/regex.h>
#include <set>

#include "FileExplorerUpdater.h"
#include "FileExplorer.h"
#include "se_globals.h"

to:

Code: [Select]
#include "FileExplorerUpdater.h"
#include "FileExplorer.h"
#include "se_globals.h"

#include <sdk.h>
#include <wx/sstream.h>
#include <wx/regex.h>
#include <set>

The main point is to move sdk.h downwards. This should be fixed in trunk. Thanks!

And another point, where the dependency can be reduced: in FileManager.h there is no need to include FileExplorer.h. Instead
a forward declaration is sufficient. The include can be moved into FileManager.cpp instead.

IMHO, the include order should follow advices of:
* Herb Sutter (C++ Coding Standards 22: "Minimize definional dependencies.[...]",
* Herb Sutter (C++ Coding Standards 23: "Make header files self-sufficient" and
 * John Lakos (Large Scale C++ Software Design: Major Design Rule "The .c[pp] file of every component should include
   its own .h file as the first substantial line of code."

Therefore, I personally would prefer the #include order.

own header
plugin
cb
wx
std

The interference with pre-compiled header is another story.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6613
    • My Best Post
Re: FileManager: Version Control Browsing
« Reply #27 on: February 21, 2015, 02:00:59 pm »

IMHO, the include order should follow advices of:
* Herb Sutter (C++ Coding Standards 22: "Minimize definional dependencies.[...]",
* Herb Sutter (C++ Coding Standards 23: "Make header files self-sufficient" and
 * John Lakos (Large Scale C++ Software Design: Major Design Rule "The .c[pp] file of every component should include
   its own .h file as the first substantial line of code."

Therefore, I personally would prefer the #include order.

own header
plugin
cb
wx
std

The interference with pre-compiled header is another story.

I prefer this order

PCH
std
wx
cb
own header

Last time I checked this header had issues "se_globals.h" so moving it till just below sdk.h might be needed till the issues are fixed.

When I have time I will see if I can submit a patch on the headers in FileManager CB Plugin.

Tim S.





« Last Edit: February 21, 2015, 06:44:35 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6613
    • My Best Post
Re: FileManager: Version Control Browsing
« Reply #28 on: February 21, 2015, 04:56:28 pm »
Quick patch that needs more testing.

https://github.com/stahta01/cb_misc/blob/master/Patches/svn/cb_PCH_FileManager.patch

Builds on Windows 7 64 Bit using 32 bit TDM GCC.
Tested both wx30 and wx28 builds.

Yes, I have finally confirmed that GCC on Linux acts like MinGW GCC and needs an include to the object folder to work.

Tested on Debian Wheezy 64 bit (wx28) it took about 30+ seconds to build without patch about 15 seconds with patch.
(The patch includes both the one linked above and the one in the code below).

Code: [Select]
Index: src/plugins/contrib/FileManager/FileManager-unix.cbp
===================================================================
--- src/plugins/contrib/FileManager/FileManager-unix.cbp (revision 10123)
+++ src/plugins/contrib/FileManager/FileManager-unix.cbp (working copy)
@@ -44,6 +44,7 @@
  <Add option="-DcbDEBUG" />
  <Add option="-DCB_PRECOMP" />
  <Add option="-D__FAM__" />
+ <Add directory="../../../.objs/include" />
  <Add directory="../../../include" />
  <Add directory="../../../sdk/wxscintilla/include" />
  <Add directory="../../../include/mozilla_chardet" />


Edit2: I plan to test Debian wxWidgets 3.0 branch once I get it built. My Internet connection is very slow today so it might be a while before I get the git checkout done.

Tim S.
« Last Edit: February 21, 2015, 06:17:21 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org