Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: stahta01 on May 05, 2014, 07:03:44 pm
-
Link to my Git copy of the rules/suggestions I am working on
Edit: New Location for rules https://github.com/stahta01/cb_misc/blob/master/Notes/Rules%20and%20suggestions%20for%20using%20PCH%20properly%20under%20Windows.txt (https://github.com/stahta01/cb_misc/blob/master/Notes/Rules%20and%20suggestions%20for%20using%20PCH%20properly%20under%20Windows.txt)
Note: This section needs additions because I have tested the compiler option "-include sdk.h" and it works better for at least some CB plugins.
Required rules for using PCH properly under Windows
1. This sdk_common.h file should only be included by sdk.h and sdk_precomp.h
2. Use sdk.h instead of sdk_precomp.h in CB Plugins
3. Do NOT include sdk.h from inside header files (unless that header is making a PCH).
4. Do NOT include wx.h or wxprec.h inside header files (unless that header is making a PCH).
5. Do NOT include a header file before include sdk.h.
6. Do NOT do a pragma before include sdk.h.
7. Should have "-Winvalid-pch" warning set.
8. Must have the folder containing sdk.k and sdk.h.gch in the search path!
NOTE: The folder containing sdk.h.gch must before the sdk.k folder.
I really would like feedback on the first rule.
Required rules for using PCH properly under Windows
1. This sdk_common.h file should only be included by sdk.h and sdk_precomp.h
If it is acceptable, I will attach a patch that fixes the problem.
Link to this patch https://github.com/stahta01/codeblocks/blob/PCH/Patches/svn/cb_src_remove_sdk_common_h_new.patch (https://github.com/stahta01/codeblocks/blob/PCH/Patches/svn/cb_src_remove_sdk_common_h_new.patch)
Note: I plan to remove the "_new" from the end of my patches in the future.
Tim S.
-
Why don't you just fork my repo and apply patches directly, then ask for a pull?
-
Why don't you just fork my repo and apply patches directly, then ask for a pull?
I will have to learn how to do this; would this result in the patches making it to Code::Blocks once you OK them?
Because I am a Git newbie, I have little experience on using Git correctly; I am willing to do it if you think it is the correct way to get the patches into the CB svn trunk. Might be a while before I learn how to do it right.
Any good URL links on how to use Git correctly you can give me?
Please give me the link to use in forking your repo?
Found it. https://github.com/obfuscated/codeblocks_sf
Tim S.
-
Hm, you can look around the help of github. There are plenty of examples.
The steps should be something like:
1. Clone the repo
2. checkout master
3. create new branch
4. make some commits
5. push the branch to your own repo
6. post here with the link to the branch
For me this way it is easier to look at patches and then try them.
-
Hm, you can look around the help of github. There are plenty of examples.
The steps should be something like:
1. Clone the repo
2. checkout master
3. create new branch
4. make some commits
5. push the branch to your own repo
6. post here with the link to the branch
For me this way it is easier to look at patches and then try them.
Link to the repo of the stuff I think ready to commit upstream.
https://github.com/stahta01/codeblocks_sf/tree/win_build_speedup (https://github.com/stahta01/codeblocks_sf/tree/win_build_speedup)
Right now, it is only the patch to remove the includes of "sdk_common.h".
Edit: Decided to delete my fork and re-create it with a minor name change.
Did too many things wrong in it.
Tim S.
-
As you probably know this one is in svn now.
When you have something ready for commit, please say so.
-
As you probably know this one is in svn now.
When you have something ready for commit, please say so.
Thank you for committing it; I am still testing the changes that adds back PCH to wx30 windows 32 bit bit.
Edit: The changes was enough for wx30 windows 32 bit; but, 64 bit did NOT work with it.
Edit: Decided to try to get 64 bit working before submitting 32 bit changes.
Edit: I also deleted and re-forking your git repo before doing more commints.
Edit: I also decided I needed to re-create the wxSmith code generation before patching the source file.
Edit: New URL https://github.com/stahta01/codeblocks_sf_tims/tree/win_build_speedup (https://github.com/stahta01/codeblocks_sf_tims/tree/win_build_speedup)
I still need to add changes to that fork.
Tim S.
-
Please post new message and don't edit old message, because people (like me) using the "show unread posts since last visit" won't see them!
-
Please post new message and don't edit old message, because people (like me) using the "show unread posts since last visit" won't see them!
OK.
I have decided that I need a Linux or BSD like box to test most of my changes on github.com/stahta01/codeblocks_sf_tims/tree/win_build_speedup
https://github.com/stahta01/codeblocks_sf_tims/tree/win_build_speedup (https://github.com/stahta01/codeblocks_sf_tims/tree/win_build_speedup)
But, till then I will work on all my patches to the CB scriptedwizard here github.com/stahta01/codeblocks_sf_tims/tree/scriptedwizard .
https://github.com/stahta01/codeblocks_sf_tims/tree/scriptedwizard (https://github.com/stahta01/codeblocks_sf_tims/tree/scriptedwizard)
I will post again after I finish the 4 to 6 sets of changes to the CB scriptedwizard.
Tim S.
-
What are you trying to do with the scripted wizzard?
-
What are you trying to do with the scripted wizzard?
Trying to get it to make good PCH compatible code.
Edit: This means moving and reordering includes of headers, adding forward declares, and adding include of sdk.h
1. Fix Plugin code using PCH correctly by adding use of sdk.h in cpp files of ScripedWizard.
2. rebuild wxCode generated by (wxSmith) Edit: This step resulted in no changes to the code.
3. rebuild wxCode using PCH headers (InternalHeadersPCH and HeadersPCH)
4. Fix wxWidget code templates
5. Fix CB Plugin code templates
6. Fix CB Plugin wizard creation of CB Project (add sdk.h.gch search folder)
Not part of planned fixes in this branch at this time.
7. Rewrite CB Plugin wizard script to add non-pch target
Tim S.
-
Not part of planned fixes in this branch at this time.
7. Rewrite CB Plugin wizard script to add non-pch target
7A. Fix building of two target of debug and release when using local PCH File.
7A1. Make location of local PCH file in object folder.
Tim S.
-
To oBFusCATed: These two changes needs to tested for build issues on a Linux box.
I have push out my local changes to my https://github.com/stahta01/codeblocks_sf_tims/tree/scriptedwizard (https://github.com/stahta01/codeblocks_sf_tims/tree/scriptedwizard)
These items 1 and 3 should NOT cause any functional change in the plugin; but, might cause compile errors because of missing include.
I have tested on windows 7 32 bit using wxWidgets 2.8.12 and found no build problems.
Note: I used the wxSmith from CB version 13.12 to generated the wxSmith code.
1. Fix Plugin code using PCH correctly by adding use of sdk.h in cpp files of ScripedWizard.
2. rebuild wxCode generated by (wxSmith) Edit: This step resulted in no changes to the code.
3. rebuild wxCode using PCH headers (InternalHeadersPCH and HeadersPCH)
Tim S.
-
I'm testing this, then. Should I commit it to trunk if it doesn't fail?
btw: Don't use git merge operations, but only git rebase, because git's merge commits are incompatible with svn's.
-
I'm testing this, then. Should I commit it to trunk if it doesn't fail?
btw: Don't use git merge operations, but only git rebase, because git's merge commits are incompatible with svn's.
Yes, please commit to svn trunk if it compiles on Linux using CB Project and configure/make.
Edit: Found out what rebase means http://git-scm.com/book/en/Git-Branching-Rebasing (http://git-scm.com/book/en/Git-Branching-Rebasing) and http://git-scm.com/docs/git-rebase.html (http://git-scm.com/docs/git-rebase.html)
Will try to do it that way in the future. I am using TortoiseGit; so, I really not sure how to use all of Git.
But, it shows a rebase command.
Tim S.
-
Doing a git reset --hard and will redo the last two changes to https://github.com/stahta01/codeblocks_sf_tims/tree/scriptedwizard
Tim S.
-
Why? I've been planning to commit them in a minute.
-
Why? I've been planning to commit them in a minute.
I am trying to figure out how to use Git and making mistakes after mistakes; if you still can apply the two commits of mine please do so.
I am trying reset/rebase my local repo to yours to get rid of the Git Merges.
Tim S.
-
Please ignore any push/pull requests from me in the last hour or so.
Note: I thought I was pulling/pushing from my github repo; but, I think it might have been yours.
Tim S.
-
In svn then...
-
In svn then...
Thank you.
Can you verify that I used rebase in a correct manner for https://github.com/stahta01/codeblocks_sf_tims/tree/scriptedwizard (https://github.com/stahta01/codeblocks_sf_tims/tree/scriptedwizard)
The single new commit is NOT yet tested enough for it to be applied upstream.
Thank you again for putting up with my learning curve on git.
Tim S.
-
Your rebase seems fine to me.
-
Your rebase seems fine to me.
Thank you for checking.
One of the things I did to fix/avoid PCH issues was updated wxFormBuilder files to version 3.0.57 (Apr 16 2008).
I hope this will be good; I think most users of wxFormBuilder likely using at least the prior stable release which is 3.0.57.
NOTE: I am still testing the wxWidgets Wizard changes; so, hold off on applying these changes.
If you wish to test the areas of changes are.
PCH file (wx_pch.h) use in Wizard (Misc. Settings: Create and use precompiled Header)
Preferred GUI Builder NONE and wxFormBuilder code changes (No changes to wxSmith project code)
Fixed Bug in CB Project creation when Misc. Settings: "Create and use precompiled Header" and "Create Empty Project" both checked.
Tim S.
-
Just undone my last 2 to 4 commits; not sure how but my Line-feeds got changed.
I hope I did not break the rebase work.
Tim S.
-
Pushed my local changes to https://github.com/stahta01/codeblocks_sf_tims/tree/scriptedwizard (https://github.com/stahta01/codeblocks_sf_tims/tree/scriptedwizard)
I tested them under Windows 32-bit using wxWidgets 2.8 and they tested well.
The only things changed are wxWidgets templates so rebuilding the ScriptedWizard Plugin is likely NOT needed.
The list of things changed are the same.
PCH file (wx_pch.h) use in Wizard (Misc. Settings: Create and use precompiled Header)
Preferred GUI Builder NONE and wxFormBuilder code changes (No changes to wxSmith GUI Builder code)
Fixed Bug in CB Project creation when Misc. Settings: "Create and use precompiled Header" and "Create Empty Project" both checked.
The most important fix from a PCH build view is moving wx/wx.h from the main.h to app.cpp/main.cpp changes.
The upgrading of the wxFormBuilder to version 3.0 is the other important PCH build change.
Please verify the wxWidget wizard runs and results in projects that build without error on Linux.
Then, I would hope these changes are able to be commited to SVN trunk.
Thank you, again.
Tim S.
-
I added patch to the CB Plugin Wizard that needs tested in my scriptedwizard branch before it is applied to SVN trunk.
It should be enough just to verify that the CB Plugin Wizard results in code that compilers and links under Linux.
Thank you
Tim S.
Pushed my local changes to https://github.com/stahta01/codeblocks_sf_tims/tree/scriptedwizard (https://github.com/stahta01/codeblocks_sf_tims/tree/scriptedwizard)
I tested them under Windows 32-bit using wxWidgets 2.8 and they tested well.
The only things changed are wxWidgets templates so rebuilding the ScriptedWizard Plugin is likely NOT needed.
The list of things changed are the same.
PCH file (wx_pch.h) use in Wizard (Misc. Settings: Create and use precompiled Header)
Preferred GUI Builder NONE and wxFormBuilder code changes (No changes to wxSmith GUI Builder code)
Fixed Bug in CB Project creation when Misc. Settings: "Create and use precompiled Header" and "Create Empty Project" both checked.
The most important fix from a PCH build view is moving wx/wx.h from the main.h to app.cpp/main.cpp changes.
The upgrading of the wxFormBuilder to version 3.0 is the other important PCH build change.
Please verify the wxWidget wizard runs and results in projects that build without error on Linux.
Then, I would hope these changes are able to be commited to SVN trunk.
Thank you, again.
Tim S.
-
Created another branch to do other changes/patches https://github.com/stahta01/codeblocks_sf_tims/tree/for_upstream (https://github.com/stahta01/codeblocks_sf_tims/tree/for_upstream)
I committed a change/patch to add PCH building back to CB under wxWidgets 3.0 Windows 32 bit (also added it to work under wxWidgets 2.8 Windows 32 bit).
The Contrib plugins I added it to is wxSmith Aui. plugin; please test to verify it works under Linux.
Please re-build just the wxSmith Aui. plugin for both wxWidgets 2.8 and 3.0 to verify that the build time is reduced by the patch under Linux.
Under Windows, the build time is reduced by 20 to 60 percent of what it is without the patch.
The patch is safe to be applied to trunk if there is no build issues under Linux.
But, if it does NOT speed up the Linux build it is NOT likely worth applying to SVN trunk.
If it works (speeds up the Linux Build); I plan to work on the wxSmith Plugin next.
Tim S.
-
Can you add an upper limit to the version check?
This way newer compilers will fail and they can be added to the check.
Otherwise it is quite possible that the wxpch won't be used for newer compilers forever until someone digs into this again and stumbles upon this check.
-
Can you add an upper limit to the version check?
This way newer compilers will fail and they can be added to the check.
Otherwise it is quite possible that the wxpch won't be used for newer compilers forever until someone digs into this again and stumbles upon this check.
What version number do you wish me to think works? 4.9 or what?
Tim S.
-
Can you add an upper limit to the version check?
This way newer compilers will fail and they can be added to the check.
Otherwise it is quite possible that the wxpch won't be used for newer compilers forever until someone digs into this again and stumbles upon this check.
What version number do you wish me to think works? 4.9 or what?
Tim S.
I will change it to a range of GCC versions stopping at either 4.9.0 or 4.9.1 for now.
Will also start at 4.7.2 (the web implies it might have started with that version.)
Will post when I get it done.
Tim S.
-
I will change it to a range of GCC versions stopping at either 4.9.0 or 4.9.1 for now.
Will also start at 4.7.2 (the web implies it might have started with that version.)
Will post when I get it done.
Tim S.
I have pushed the change; the undef should stop at 4.9.0; so GCC 4.9.1 will result in PCH size crash if bug not fixed by then.
Tim S.