Re: Building on Windows from scratch - guile problem SOLVED
On Thursday 16 January 2014 14:26:41 Geert Janssens wrote: > Gary, > > While looking at your changes I noticed you changed two lines in > the vbs script. > > One is that you added my repository/branch in a comment. > That's ok and makes it easier for others to start. > > The second is to install msys-patch. Is there a reason you do this > in the vbs script and not in install-impl.sh ? > > Geert > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel Gary, A late update on this. I have tried to apply your patches to my branch. The first two were already integrated. Of the other 5 only two could be applied cleanly. I have added one more manually, but two are currently not applied. I have just rebased my branch from the most recent trunk. Can you pull my branch (with git pull --rebase) and check which parts are missing and recreate patches for these items ? Thanks, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 18/01/2014 09:53, Geert Janssens wrote: On Friday 17 January 2014 07:30:00 John Ralls wrote: > > > > OK Geert, > > I think I have what you want at > > http://www.greenwheel.com/publicFiles/rebase-patches.zip Let me > > know if this works for you. > > Not being a git expert, it's possible I've not quite done the right > > thing, but I think this should be OK. > As another option, perhaps the most "git-ish" (sorry) of all, would be > for Gary to get a (free) Github account, fork Geert's repo, make his > branch, push that back to *his* repo, and then from Github send Geert > a pull request. > > I know I've argued against allowing this in the past, but I'm coming > around to the idea that we need to make it easier for folks to offer > patches. > Heh, I didn't want to propose this exactly because of your opposition in the past. But I have been thinking of leveraging github's pull requests as well. I see for example that swig is using this approach rather succesfully. I can imagine that a project the size of a linux kernel needs some stricter rules to keep organized. But GnuCash is pretty small in comparison. Reminds me we still have to discuss our future branching strategy, but that's for another thread. Back to the patches at hand: Gary, I tried to download the zip file you made available, but I get a permission error on that website. Can you check that ? Geert Sorry Geert, forgot to add read perms to the file. Should be OK now. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Friday 17 January 2014 07:30:00 John Ralls wrote: > > > > OK Geert, > > I think I have what you want at > > http://www.greenwheel.com/publicFiles/rebase-patches.zip Let me > > know if this works for you. > > Not being a git expert, it's possible I've not quite done the right > > thing, but I think this should be OK. > As another option, perhaps the most "git-ish" (sorry) of all, would be > for Gary to get a (free) Github account, fork Geert's repo, make his > branch, push that back to *his* repo, and then from Github send Geert > a pull request. > > I know I've argued against allowing this in the past, but I'm coming > around to the idea that we need to make it easier for folks to offer > patches. > Heh, I didn't want to propose this exactly because of your opposition in the past. But I have been thinking of leveraging github's pull requests as well. I see for example that swig is using this approach rather succesfully. I can imagine that a project the size of a linux kernel needs some stricter rules to keep organized. But GnuCash is pretty small in comparison. Reminds me we still have to discuss our future branching strategy, but that's for another thread. Back to the patches at hand: Gary, I tried to download the zip file you made available, but I get a permission error on that website. Can you check that ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Jan 17, 2014, at 7:39 AM, John Ralls wrote: > > On Jan 16, 2014, at 7:53 AM, Geert Janssens wrote: > >> On Thursday 16 January 2014 07:49:53 John Ralls wrote: >>> On Jan 16, 2014, at 5:23 AM, Geert Janssens >>> wrote: 3. Apply your patches and ignore those that are already there is also correct. Then before committing anything it's worth considering which changes logically belong together and check these changes in in separate commits. 'git add -i' will be tremendously helpful for this part (adding changes into the index interactively). >>> >>> Pardon me for barging in. I just want to add that a git GUI makes it >>> much less painful to pull diffs apart into commits compared to `git >>> add -i`. TortoiseGit (http://code.google.com/p/tortoisegit/) works >>> well on M$Windows. >>> >>> Regards, >>> John Ralls >> >> Interesting. I never used a gui for this yet. Which one do you use on your >> mac ? > > I'd been using GitX [1], but it's pretty buggy and crash-prone, so I've > lately switched to Atlassian Stash [2], which is free as in beer instead > Free, but it hasn't yet crashed on me. Oops, that’s wrong. It’s Atlassian SourceTree: http://www.sourcetreeapp.com/ Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Jan 16, 2014, at 7:53 AM, Geert Janssens wrote: > On Thursday 16 January 2014 07:49:53 John Ralls wrote: > > On Jan 16, 2014, at 5:23 AM, Geert Janssens > > wrote: > > > 3. Apply your patches and ignore those that are already there is > > > also correct. Then before committing anything it's worth > > > considering which changes logically belong together and check these > > > changes in in separate commits. 'git add -i' will be tremendously > > > helpful for this part (adding changes into the index > > > interactively). > > > > Pardon me for barging in. I just want to add that a git GUI makes it > > much less painful to pull diffs apart into commits compared to `git > > add -i`. TortoiseGit (http://code.google.com/p/tortoisegit/) works > > well on M$Windows. > > > > Regards, > > John Ralls > > Interesting. I never used a gui for this yet. Which one do you use on your > mac ? I'd been using GitX [1], but it's pretty buggy and crash-prone, so I've lately switched to Atlassian Stash [2], which is free as in beer instead Free, but it hasn't yet crashed on me. On Linux I use gitx and giggle, both of which are in all of the package managers. Regards, John Ralls [1] http://gitx.org/ [2] https://www.atlassian.com/software/stash/overview ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Jan 17, 2014, at 7:30 AM, John Ralls wrote: > > On Jan 17, 2014, at 5:57 AM, Gary Bilkus wrote: > >> On 16/01/2014 13:23, Geert Janssens wrote: >>> >>> On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote: >>> >>> So just to make sure I understand exactly what you need. >>> >>> 1. I should get the gnucash.git repository from >>> git://github.com:gjanssens/gnucash.git >>> 2. I should git branch -t mingw origin/mingw-rebasing and check out >>> that branch >>> 3. I should appy my patches to that branch - ignoring any which are >>> already there >>> 4. I should run git diff to get a series of patches against the branch >>> in the repository >>> 5. I should split the resulting diff into different files relating to >>> the different fixes >>> 6. I should post the result somewhere and tell you where it is >>> >>> Gary >>> >>> Gary, >>> >>> That's close. But git's workflow is slightly different: >>> >>> 1 and 2 are correct >>> >>> 3. Apply your patches and ignore those that are already there is also >>> correct. Then before committing anything it's worth considering which >>> changes logically belong together and check these changes in in separate >>> commits. 'git add -i' will be tremendously helpful for this part (adding >>> changes into the index interactively). >>> >>> 4. Each time you have added a coherent set of changes to the index file, >>> you can create a (local) commit using 'git commit'. You may want to use >>> clear commit messages in this step as they will eventually end up in the >>> master repository. You can look at my commits for examples but they're only >>> that not hard rules. I suggest though that you explicitly add an author >>> line in your commit message. Since we're still linked to the svn repo, >>> git's author information gets lost for non-committers when we commit to the >>> master repository. This line is in the form: >>> >>> Author: name >>> >>> 5. When there are no more changes to commit, you can run 'git format-patch' >>> to generate a series of patch files like so: >>> >>> git format-patch origin/mingw-rebasing >>> >>> That should generate the patch files in the current working directory. >>> >>> 6. The normal way to make these patches available to me is to create an >>> enhancement request in bugzilla and attach the patches there. But in this >>> case I'm equally fine if you post them to the list or tell me where you >>> stored them on your own server or whatever. >>> >>> Geert >>> >> OK Geert, >> I think I have what you want at >> http://www.greenwheel.com/publicFiles/rebase-patches.zip >> Let me know if this works for you. >> Not being a git expert, it's possible I've not quite done the right thing, >> but I think this should be OK. > > As another option, perhaps the most "git-ish" (sorry) of all, would be for > Gary to get a (free) Github account, fork Geert's repo, make his branch, push > that back to *his* repo, and then from Github send Geert a pull request. > > I know I've argued against allowing this in the past, but I'm coming around > to the idea that we need to make it easier for folks to offer patches. I'll add that this finesses > The reason I added in msys-patch to my version of your script is so that the > instructions I posted on the wiki would work, since they tell you to run your > vbs script and then run patch against the 2.6 repo with my patchfile, and > that doesn't work if you don't yet have patch installed. > > Of course, as and when there's a git repo with the patches already > incorporated, that step is no longer needed and nor is patch. But it doesn't > do much harm to leave it around, and would make it easier for people who have > to play catch-up the next time a downstream dependency gets broken. because there's instantly a published git repository with the patches incorporated! Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Jan 17, 2014, at 5:57 AM, Gary Bilkus wrote: > On 16/01/2014 13:23, Geert Janssens wrote: >> >> On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote: >> >> > >> >> > So just to make sure I understand exactly what you need. >> >> > >> >> > 1. I should get the gnucash.git repository from >> >> > git://github.com:gjanssens/gnucash.git >> >> > 2. I should git branch -t mingw origin/mingw-rebasing and check out >> >> > that branch >> >> > 3. I should appy my patches to that branch - ignoring any which are >> >> > already there >> >> > 4. I should run git diff to get a series of patches against the branch >> >> > in the repository >> >> > 5. I should split the resulting diff into different files relating to >> >> > the different fixes >> >> > 6. I should post the result somewhere and tell you where it is >> >> > >> >> > Gary >> >> Gary, >> >> That's close. But git's workflow is slightly different: >> >> 1 and 2 are correct >> >> 3. Apply your patches and ignore those that are already there is also >> correct. Then before committing anything it's worth considering which >> changes logically belong together and check these changes in in separate >> commits. 'git add -i' will be tremendously helpful for this part (adding >> changes into the index interactively). >> >> 4. Each time you have added a coherent set of changes to the index file, you >> can create a (local) commit using 'git commit'. You may want to use clear >> commit messages in this step as they will eventually end up in the master >> repository. You can look at my commits for examples but they're only that >> not hard rules. I suggest though that you explicitly add an author line in >> your commit message. Since we're still linked to the svn repo, git's author >> information gets lost for non-committers when we commit to the master >> repository. This line is in the form: >> >> Author: name >> >> 5. When there are no more changes to commit, you can run 'git format-patch' >> to generate a series of patch files like so: >> >> git format-patch origin/mingw-rebasing >> >> That should generate the patch files in the current working directory. >> >> 6. The normal way to make these patches available to me is to create an >> enhancement request in bugzilla and attach the patches there. But in this >> case I'm equally fine if you post them to the list or tell me where you >> stored them on your own server or whatever. >> >> Geert >> > OK Geert, > I think I have what you want at > http://www.greenwheel.com/publicFiles/rebase-patches.zip > Let me know if this works for you. > Not being a git expert, it's possible I've not quite done the right thing, > but I think this should be OK. As another option, perhaps the most "git-ish" (sorry) of all, would be for Gary to get a (free) Github account, fork Geert's repo, make his branch, push that back to *his* repo, and then from Github send Geert a pull request. I know I've argued against allowing this in the past, but I'm coming around to the idea that we need to make it easier for folks to offer patches. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 16/01/2014 13:23, Geert Janssens wrote: On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote: > > So just to make sure I understand exactly what you need. > > 1. I should get the gnucash.git repository from > git://github.com:gjanssens/gnucash.git > 2. I should git branch -t mingw origin/mingw-rebasing and check out > that branch > 3. I should appy my patches to that branch - ignoring any which are > already there > 4. I should run git diff to get a series of patches against the branch > in the repository > 5. I should split the resulting diff into different files relating to > the different fixes > 6. I should post the result somewhere and tell you where it is > > Gary Gary, That's close. But git's workflow is slightly different: 1 and 2 are correct 3. Apply your patches and ignore those that are already there is also correct. Then before committing anything it's worth considering which changes logically belong together and check these changes in in separate commits. 'git add -i' will be tremendously helpful for this part (adding changes into the index interactively). 4. Each time you have added a coherent set of changes to the index file, you can create a (local) commit using 'git commit'. You may want to use clear commit messages in this step as they will eventually end up in the master repository. You can look at my commits for examples but they're only that not hard rules. I suggest though that you explicitly add an author line in your commit message. Since we're still linked to the svn repo, git's author information gets lost for non-committers when we commit to the master repository. This line is in the form: Author: name 5. When there are no more changes to commit, you can run 'git format-patch' to generate a series of patch files like so: git format-patch origin/mingw-rebasing That should generate the patch files in the current working directory. 6. The normal way to make these patches available to me is to create an enhancement request in bugzilla and attach the patches there. But in this case I'm equally fine if you post them to the list or tell me where you stored them on your own server or whatever. Geert OK Geert, I think I have what you want at http://www.greenwheel.com/publicFiles/rebase-patches.zip Let me know if this works for you. Not being a git expert, it's possible I've not quite done the right thing, but I think this should be OK. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 16/01/2014 15:38, Geert Janssens wrote: On Thursday 16 January 2014 15:06:55 Gary Bilkus wrote: > On 16/01/2014 13:26, Geert Janssens wrote: > > Gary, > > > > While looking at your changes I noticed you changed two lines in the > > vbs script. > > > > One is that you added my repository/branch in a comment. That's ok > > and makes it easier for others to start. > > > > The second is to install msys-patch. Is there a reason you do this > > in > > the vbs script and not in install-impl.sh ? > > > > Geert > > Hi Geert. > The reason I added in msys-patch to my version of your script is so > that the instructions I posted on the wiki would work, since they > tell you to run your vbs script and then run patch against the 2.6 > repo with my patchfile, and that doesn't work if you don't yet have > patch installed. > > Of course, as and when there's a git repo with the patches already > incorporated, that step is no longer needed and nor is patch. But it > doesn't do much harm to leave it around, and would make it easier for > people who have to play catch-up the next time a downstream dependency > gets broken. > Gary Hi Gary, That makes sense. The reason I'm very cautious about adding stuff in the bootstrap script is that mingw-get is fairly fragile. The bootstrap script unconditionally installs the most recent version of the various packages, but in the install.sh script we force specific versions. If at some point the most recent version is more recent than what we explicitly set this will probably cause mingw-get to error out. That may or may not be bad but at least pretty confusing to new users. We may fix this by installing very specific versions in the bootstrap script already instead of the latest available. Although that approach risks that these versions will at some point get out of sync with the versions defined in defaults.sh. But IMO that is less of an issue. If this happens the installation script will update the packages to the proper versions without errors the first time it runs. I'll admit this is close to nitpicking. There are bigger issues to solve right now, but I mention it because now I noticed it. I will probably forget later on. Geert I completely understand the thinking. That said, I think patch is probably a pretty safe program to just download, given its longevity and stability at this point, compared to things like say the c compiler! ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Thursday 16 January 2014 07:49:53 John Ralls wrote: > On Jan 16, 2014, at 5:23 AM, Geert Janssens wrote: > > 3. Apply your patches and ignore those that are already there is > > also correct. Then before committing anything it's worth > > considering which changes logically belong together and check these > > changes in in separate commits. 'git add -i' will be tremendously > > helpful for this part (adding changes into the index > > interactively). > > Pardon me for barging in. I just want to add that a git GUI makes it > much less painful to pull diffs apart into commits compared to `git > add -i`. TortoiseGit (http://code.google.com/p/tortoisegit/) works > well on M$Windows. > > Regards, > John Ralls Interesting. I never used a gui for this yet. Which one do you use on your mac ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Jan 16, 2014, at 5:23 AM, Geert Janssens wrote: > 3. Apply your patches and ignore those that are already there is also > correct. Then before > committing anything it's worth considering which changes logically belong > together and check > these changes in in separate commits. 'git add -i' will be tremendously > helpful for this part > (adding changes into the index interactively). Pardon me for barging in. I just want to add that a git GUI makes it much less painful to pull diffs apart into commits compared to `git add -i`. TortoiseGit (http://code.google.com/p/tortoisegit/) works well on M$Windows. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Thursday 16 January 2014 15:06:55 Gary Bilkus wrote: > On 16/01/2014 13:26, Geert Janssens wrote: > > Gary, > > > > While looking at your changes I noticed you changed two lines in the > > vbs script. > > > > One is that you added my repository/branch in a comment. That's ok > > and makes it easier for others to start. > > > > The second is to install msys-patch. Is there a reason you do this > > in > > the vbs script and not in install-impl.sh ? > > > > Geert > > Hi Geert. > The reason I added in msys-patch to my version of your script is so > that the instructions I posted on the wiki would work, since they > tell you to run your vbs script and then run patch against the 2.6 > repo with my patchfile, and that doesn't work if you don't yet have > patch installed. > > Of course, as and when there's a git repo with the patches already > incorporated, that step is no longer needed and nor is patch. But it > doesn't do much harm to leave it around, and would make it easier for > people who have to play catch-up the next time a downstream dependency > gets broken. > Gary Hi Gary, That makes sense. The reason I'm very cautious about adding stuff in the bootstrap script is that mingw-get is fairly fragile. The bootstrap script unconditionally installs the most recent version of the various packages, but in the install.sh script we force specific versions. If at some point the most recent version is more recent than what we explicitly set this will probably cause mingw-get to error out. That may or may not be bad but at least pretty confusing to new users. We may fix this by installing very specific versions in the bootstrap script already instead of the latest available. Although that approach risks that these versions will at some point get out of sync with the versions defined in defaults.sh. But IMO that is less of an issue. If this happens the installation script will update the packages to the proper versions without errors the first time it runs. I'll admit this is close to nitpicking. There are bigger issues to solve right now, but I mention it because now I noticed it. I will probably forget later on. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 16/01/2014 13:26, Geert Janssens wrote: Gary, While looking at your changes I noticed you changed two lines in the vbs script. One is that you added my repository/branch in a comment. That's ok and makes it easier for others to start. The second is to install msys-patch. Is there a reason you do this in the vbs script and not in install-impl.sh ? Geert Hi Geert. The reason I added in msys-patch to my version of your script is so that the instructions I posted on the wiki would work, since they tell you to run your vbs script and then run patch against the 2.6 repo with my patchfile, and that doesn't work if you don't yet have patch installed. Of course, as and when there's a git repo with the patches already incorporated, that step is no longer needed and nor is patch. But it doesn't do much harm to leave it around, and would make it easier for people who have to play catch-up the next time a downstream dependency gets broken. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
Gary, While looking at your changes I noticed you changed two lines in the vbs script. One is that you added my repository/branch in a comment. That's ok and makes it easier for others to start. The second is to install msys-patch. Is there a reason you do this in the vbs script and not in install-impl.sh ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote: > > So just to make sure I understand exactly what you need. > > 1. I should get the gnucash.git repository from > git://github.com:gjanssens/gnucash.git > 2. I should git branch -t mingw origin/mingw-rebasing and check out > that branch > 3. I should appy my patches to that branch - ignoring any which are > already there > 4. I should run git diff to get a series of patches against the branch > in the repository > 5. I should split the resulting diff into different files relating to > the different fixes > 6. I should post the result somewhere and tell you where it is > > Gary Gary, That's close. But git's workflow is slightly different: 1 and 2 are correct 3. Apply your patches and ignore those that are already there is also correct. Then before committing anything it's worth considering which changes logically belong together and check these changes in in separate commits. 'git add -i' will be tremendously helpful for this part (adding changes into the index interactively). 4. Each time you have added a coherent set of changes to the index file, you can create a (local) commit using 'git commit'. You may want to use clear commit messages in this step as they will eventually end up in the master repository. You can look at my commits for examples but they're only that not hard rules. I suggest though that you explicitly add an author line in your commit message. Since we're still linked to the svn repo, git's author information gets lost for non-committers when we commit to the master repository. This line is in the form: Author: name 5. When there are no more changes to commit, you can run 'git format-patch' to generate a series of patch files like so: git format-patch origin/mingw-rebasing That should generate the patch files in the current working directory. 6. The normal way to make these patches available to me is to create an enhancement request in bugzilla and attach the patches there. But in this case I'm equally fine if you post them to the list or tell me where you stored them on your own server or whatever. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 16/01/2014 11:43, Geert Janssens wrote: On Thursday 16 January 2014 11:10:30 Geert Janssens wrote: Gary, Thanks for all your updates. Today I found some time to check which of your fixes I should still add to my windows branch, but got lost in your patch. It looks like you are generating a patch to be applied to the current trunk branch, including all the separate commits from my branch. Unfortunately that makes it hard if not impossible to see only the changes needed on my branch. It's not the intention to apply such a large patch one day to current trunk. Instead my branch will be merged in eventually (likely after the 2.6 branch is generated and certainly not before the dist part and build server scripts are also fixed). So can you extract only the changes that still need to be applied to my branch please ? Ideally split up in small patches per topic (fix -no-undefined, fix guile's str_ncase_comp, ...). That way we generate clean and readable history in the repository. You may want to set up your own clone of the git repository [1] as git can be very helpful in generating such patches. Thanks, Geert [1] http://wiki.gnucash.org/wiki/Git#Non-Committers Also note that I have rebased the mingw-rebasing branch again in my repository to pick up the most recent version of aqbanking and gwenview. I haven't had the opportunity yet to check if these versions build in the new mingw environment. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel So just to make sure I understand exactly what you need. 1. I should get the gnucash.git repository from git://github.com:gjanssens/gnucash.git 2. I should git branch -t mingw origin/mingw-rebasing and check out that branch 3. I should appy my patches to that branch - ignoring any which are already there 4. I should run git diff to get a series of patches against the branch in the repository 5. I should split the resulting diff into different files relating to the different fixes 6. I should post the result somewhere and tell you where it is Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Thursday 16 January 2014 11:10:30 Geert Janssens wrote: > > Gary, > > Thanks for all your updates. Today I found some time to check which of > your fixes I should still add to my windows branch, but got lost in > your patch. It looks like you are generating a patch to be applied to > the current trunk branch, including all the separate commits from my > branch. Unfortunately that makes it hard if not impossible to see > only the changes needed on my branch. > > It's not the intention to apply such a large patch one day to current > trunk. Instead my branch will be merged in eventually (likely after > the 2.6 branch is generated and certainly not before the dist part > and build server scripts are also fixed). > > So can you extract only the changes that still need to be applied to > my branch please ? Ideally split up in small patches per topic (fix > -no-undefined, fix guile's str_ncase_comp, ...). That way we generate > clean and readable history in the repository. > You may want to set up your own clone of the git repository [1] as git > can be very helpful in generating such patches. > > Thanks, > > Geert > > [1] http://wiki.gnucash.org/wiki/Git#Non-Committers Also note that I have rebased the mingw-rebasing branch again in my repository to pick up the most recent version of aqbanking and gwenview. I haven't had the opportunity yet to check if these versions build in the new mingw environment. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Friday 10 January 2014 17:41:15 Gary Bilkus wrote: > On 10/01/2014 15:03, John Ralls wrote: > > On Jan 9, 2014, at 11:13 PM, Gary Bilkus wrote: > >> Well, interestingly enough, the problem is not directly with the > >> compiler optimizer. It's with the configure test for strncasecmp. > >> This test fails on mingw in its current incarnation because guile > >> uses a standard test for the function, but on mingw strncasecmp is > >> actually a cpp definition. As a result, guile is compiled with > >> #HAVE_STRNCASECMP unset, and so guile tries to create its own > >> version in read.c Now if you compile with no optimization, the > >> compiler notices that read.c is attempting to create this with a > >> different signature and bombs out. However, with optimisation on, > >> the code compiles for some reason, and then fails to run properly. > >> > >> So there seem to be two problems: one in configure for guile and/or > >> the standard configure macros on mingw, the other in the compiler. > >> Fortunately, there's a very easy although ugly workaround, which > >> is to add an echo "#define HAVE_STRNCASECMP" >>config.h > > > > Would adding -DHAVE_STRNCASECMP to $CFLAGS work? It's a bit cleaner > > than echoing a #define into the config header. Better yet, > > sometimes there's a variable that can be defined on the configure > > command line -- perhaps $ac_have_strncasecmp -- to force configure > > to do the right thing.> > >> in install-impl.sh > >> just after the guile configure and before the make > >> > >> I've incorporated this fix into my downloadable file of fixes as > >> referred to on the wiki page I updated. More as and when I find > >> any further issues. As always, feedback or other experiences > >> welcome.> > > Regards, > > John Ralls > > I agree that the configure commandline change would be cleaner, and if > I can find out what to do I'll change my fix. > > I disagree that a CFLAGS define is cleaner. With my solution the > define is in the right file, even if it gets there for the wrong > reason. That way, it guarantees not to affect any compilation which > doesn't involve including config.h, which saves having to check for > any unexpected consequenses elsewhere. > Gary > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel Gary, Thanks for all your updates. Today I found some time to check which of your fixes I should still add to my windows branch, but got lost in your patch. It looks like you are generating a patch to be applied to the current trunk branch, including all the separate commits from my branch. Unfortunately that makes it hard if not impossible to see only the changes needed on my branch. It's not the intention to apply such a large patch one day to current trunk. Instead my branch will be merged in eventually (likely after the 2.6 branch is generated and certainly not before the dist part and build server scripts are also fixed). So can you extract only the changes that still need to be applied to my branch please ? Ideally split up in small patches per topic (fix -no-undefined, fix guile's str_ncase_comp, ...). That way we generate clean and readable history in the repository. You may want to set up your own clone of the git repository [1] as git can be very helpful in generating such patches. Thanks, Geert [1] http://wiki.gnucash.org/wiki/Git#Non-Committers ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Fwd: Building on Windows from scratch - guile problem SOLVED
Begin forwarded message: > From: Gary Bilkus > Subject: Re: Building on Windows from scratch - guile problem SOLVED > Date: January 10, 2014 at 2:21:54 PM PST > To: John Ralls > > On 10/01/2014 17:41, Gary Bilkus wrote: >> On 10/01/2014 15:03, John Ralls wrote: >>> On Jan 9, 2014, at 11:13 PM, Gary Bilkus wrote: >>> >>>> Well, interestingly enough, the problem is not directly with the compiler >>>> optimizer. It's with the configure test for strncasecmp. This test fails >>>> on mingw in its current incarnation because guile uses a standard test for >>>> the function, but on mingw strncasecmp is actually a cpp definition. As a >>>> result, guile is compiled with #HAVE_STRNCASECMP unset, and so guile tries >>>> to create its own version in read.c >>>> Now if you compile with no optimization, the compiler notices that read.c >>>> is attempting to create this with a different signature and bombs out. >>>> However, with optimisation on, the code compiles for some reason, and then >>>> fails to run properly. >>>> >>>> So there seem to be two problems: one in configure for guile and/or the >>>> standard configure macros on mingw, the other in the compiler. >>>> Fortunately, there's a very easy although ugly workaround, which is to add >>>> an >>>> echo "#define HAVE_STRNCASECMP" >>config.h >>> Would adding -DHAVE_STRNCASECMP to $CFLAGS work? It's a bit cleaner than >>> echoing a #define into the config header. >>> Better yet, sometimes there's a variable that can be defined on the >>> configure command line -- perhaps $ac_have_strncasecmp -- to force >>> configure to do the right thing. >>> >>>> in install-impl.sh >>>> just after the guile configure and before the make >>>> >>>> I've incorporated this fix into my downloadable file of fixes as referred >>>> to on the wiki page I updated. >>>> More as and when I find any further issues. As always, feedback or other >>>> experiences welcome. >>> Regards, >>> John Ralls >>> >> I agree that the configure commandline change would be cleaner, and if I can >> find out what to do I'll change my fix. >> >> I disagree that a CFLAGS define is cleaner. With my solution the define is >> in the right file, even if it gets there for the wrong reason. That way, it >> guarantees not to affect any compilation which doesn't involve including >> config.h, which saves having to check for any unexpected consequenses >> elsewhere. >> Gary > OK. I've found the cleaner fix. You add ac_cv_func_strncasecmp=yes as a > command line argument to guile configure and then all seems good. > Have updated my patch accordingly. > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 10/01/2014 15:03, John Ralls wrote: On Jan 9, 2014, at 11:13 PM, Gary Bilkus wrote: Well, interestingly enough, the problem is not directly with the compiler optimizer. It's with the configure test for strncasecmp. This test fails on mingw in its current incarnation because guile uses a standard test for the function, but on mingw strncasecmp is actually a cpp definition. As a result, guile is compiled with #HAVE_STRNCASECMP unset, and so guile tries to create its own version in read.c Now if you compile with no optimization, the compiler notices that read.c is attempting to create this with a different signature and bombs out. However, with optimisation on, the code compiles for some reason, and then fails to run properly. So there seem to be two problems: one in configure for guile and/or the standard configure macros on mingw, the other in the compiler. Fortunately, there's a very easy although ugly workaround, which is to add an echo "#define HAVE_STRNCASECMP" >>config.h Would adding -DHAVE_STRNCASECMP to $CFLAGS work? It's a bit cleaner than echoing a #define into the config header. Better yet, sometimes there's a variable that can be defined on the configure command line -- perhaps $ac_have_strncasecmp -- to force configure to do the right thing. in install-impl.sh just after the guile configure and before the make I've incorporated this fix into my downloadable file of fixes as referred to on the wiki page I updated. More as and when I find any further issues. As always, feedback or other experiences welcome. Regards, John Ralls I agree that the configure commandline change would be cleaner, and if I can find out what to do I'll change my fix. I disagree that a CFLAGS define is cleaner. With my solution the define is in the right file, even if it gets there for the wrong reason. That way, it guarantees not to affect any compilation which doesn't involve including config.h, which saves having to check for any unexpected consequenses elsewhere. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Jan 9, 2014, at 11:13 PM, Gary Bilkus wrote: > Well, interestingly enough, the problem is not directly with the compiler > optimizer. It's with the configure test for strncasecmp. This test fails on > mingw in its current incarnation because guile uses a standard test for the > function, but on mingw strncasecmp is actually a cpp definition. As a result, > guile is compiled with #HAVE_STRNCASECMP unset, and so guile tries to create > its own version in read.c > Now if you compile with no optimization, the compiler notices that read.c is > attempting to create this with a different signature and bombs out. However, > with optimisation on, the code compiles for some reason, and then fails to > run properly. > > So there seem to be two problems: one in configure for guile and/or the > standard configure macros on mingw, the other in the compiler. > Fortunately, there's a very easy although ugly workaround, which is to add an > echo "#define HAVE_STRNCASECMP" >>config.h Would adding -DHAVE_STRNCASECMP to $CFLAGS work? It's a bit cleaner than echoing a #define into the config header. Better yet, sometimes there's a variable that can be defined on the configure command line -- perhaps $ac_have_strncasecmp -- to force configure to do the right thing. > in install-impl.sh > just after the guile configure and before the make > > I've incorporated this fix into my downloadable file of fixes as referred to > on the wiki page I updated. > More as and when I find any further issues. As always, feedback or other > experiences welcome. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
Well, interestingly enough, the problem is not directly with the compiler optimizer. It's with the configure test for strncasecmp. This test fails on mingw in its current incarnation because guile uses a standard test for the function, but on mingw strncasecmp is actually a cpp definition. As a result, guile is compiled with #HAVE_STRNCASECMP unset, and so guile tries to create its own version in read.c Now if you compile with no optimization, the compiler notices that read.c is attempting to create this with a different signature and bombs out. However, with optimisation on, the code compiles for some reason, and then fails to run properly. So there seem to be two problems: one in configure for guile and/or the standard configure macros on mingw, the other in the compiler. Fortunately, there's a very easy although ugly workaround, which is to add an echo "#define HAVE_STRNCASECMP" >>config.h in install-impl.sh just after the guile configure and before the make I've incorporated this fix into my downloadable file of fixes as referred to on the wiki page I updated. More as and when I find any further issues. As always, feedback or other experiences welcome. Gary On 09/01/2014 16:49, Gary Bilkus wrote: Hmm, The problem appears to be with the compiler optimiser doing something too aggressive, If I manually recompile guile with -O0 instead of -O2 the problem seems to go away. This could be caused by one of the new optimisations in the more recent versions of gcc in which case it could start to matter on *nix at some point. Anyone know much about this? Gary -Original message- From:Gary Bilkus Sent:Thu 09-01-2014 13:37 Subject:Building on Windows from scratch - guile problem To:gnucash-devel@gnucash.org; I have done some testing of my build, and it appears there is some kind of problem with guile The symptom is that whenever I try to run a report, even hello world, it fails. Digging into things, it turns out that there is at least one problem with the guile build, whcih is that character constants like #\space are not being initialized correctly. Just running guile standalone shows the problem. guile> #\space \#nul So there's obviously some problem with the guile build over and above the library naming one I found earlier. Not sure if it's the version, the compiler version or what. Will investigate further, but any suggestions or experience from other would be welcome Gary On 08/01/2014 15:07, Gary Bilkus wrote: I have written up the procedure which as of today is working to build gnucash 2.6 from scratch on windows and updated http://wiki.gnucash.org/wiki/Windows/Development It would be really nice if the patch file I have created along with my modified version of geert's vbs file could find their way into the official repo. It should be safe enough as all the changes are to the win32 directory except for two, which I'm reasonably confident won't break anything else: - configure.ac now deals with the -no-undefined flag more cleverly - gnc-split-reg.h has a couple of #undef statements added to avoid DELETE and DUPLICATE being defined in windows headers. It probably also makes sense for the page to be split up again, and some of the older information moved away, but it would be good to get some feedback from people who try following the instructions. I've done my best to ensure that there are no ambiguities or misprints, and the entire process has worked for me, but feel free to fix any errors, or tell me of any changes I can/should make to the zip file I've published. Please note that I haven't extensively tested all the features of the program. There could be some issues with the build which don't immediately manifest themselves..but at least it runs. Also, I haven't yet tried packaging the app into an msi or installable exe Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
