[fossil-users] how to fix links to wiki pages if project name is changed?
I just stumbled over this: the URL of the home wiki page contains the project name as a prefix. if the project names is changed _after_ that wiki page has been created/edited, the 'home' link obviously points somewhere else... I understand that I can fix this by explicitely specifying the correct URL for the index page but still this means that both new and old project name are diplayed on the home page. so is there a way to change somehow the names/URLs of existing wiki pages? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to fix links to wiki pages if project name is changed?
On Thu, Oct 10, 2013 at 7:54 AM, j. van den hoff veedeeh...@googlemail.comwrote: I just stumbled over this: the URL of the home wiki page contains the project name as a prefix. if the project names is changed _after_ that wiki page has been created/edited, the 'home' link obviously points somewhere else... I understand that I can fix this by explicitely specifying the correct URL for the index page but still this means that both new and old project name are diplayed on the home page. so is there a way to change somehow the names/URLs of existing wiki pages? Under Admin/Configuration you can set the Index Page to whatever you want. Or, if you just want to change the Home link on the menu bar, you can visit Admin/Header and edit the page header text to make Home point where you want, or completely change around the menu options, if desired. Notice that the Fossil homepage uses a non-standard menu, for example. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to fix links to wiki pages if project name is changed?
On Thu, 10 Oct 2013 13:59:28 +0200, Richard Hipp d...@sqlite.org wrote: On Thu, Oct 10, 2013 at 7:54 AM, j. van den hoff veedeeh...@googlemail.comwrote: I just stumbled over this: the URL of the home wiki page contains the project name as a prefix. if the project names is changed _after_ that wiki page has been created/edited, the 'home' link obviously points somewhere else... I understand that I can fix this by explicitely specifying the correct URL for the index page but still this means that both new and old project name are diplayed on the home page. so is there a way to change somehow the names/URLs of existing wiki pages? Under Admin/Configuration you can set the Index Page to whatever you want. yes, I understand this. in this way I can get the wiki page with the URL containing the old project name working again. but the old project name will then still be displayed as the name of that wiki page. so if I change the project name from red to green I get a home page with the header green and the subheader red where usually I would see the same header twice. so the question is, whether on can edit the name/url of existing wiki pages. apart from this: would it not be possible to treat the default home page special and to avoid to actually show the same header twice? ideally the home page should show the project name only once. pure cosmetics, of course... Or, if you just want to change the Home link on the menu bar, you can visit Admin/Header and edit the page header text to make Home point where you want, or completely change around the menu options, if desired. Notice that the Fossil homepage uses a non-standard menu, for example. currently not an issue, but good to know, thanks. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to fix links to wiki pages if project name is changed?
On Thu, Oct 10, 2013 at 8:07 AM, j. van den hoff veedeeh...@googlemail.comwrote: so the question is, whether on can edit the name/url of existing wiki pages. No. The wiki page name is the primary key used in the low-level artifacts that record wiki pages, so there is no way to change the name after the fact. Though, you can create a new wiki page with the new name. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] mingw doesn't build anymore on win8-64bit
Hi list.. I recently try to compile latest trunk and the build failed.. Since I was already using a version I compile myself from 1 or 2 month ago, I decide to do a bisect to find which commit break it. So here my bisect result: $ fossil bisect chart 1 BAD 2013-10-09 13:58:55 6981cc6851ed5f3a 3 BAD 2013-09-30 14:45:45 238c8dafd070b99a 5 BAD 2013-09-27 04:08:16 1a30da30db0b2385 7 BAD 2013-09-26 07:17:32 a8214df37230c2de 8 GOOD2013-09-26 06:58:59 f2ce2f80f43edd4e 9 CURRENT 2013-09-26 06:58:59 f2ce2f80f43edd4e 6 GOOD2013-09-25 23:56:32 6b58c67ed8f95c32 4 GOOD2013-09-19 11:18:33 add752453332cdc3 2 GOOD2013-09-16 20:01:07 b5141cb799cb20a2 It happens that the only difference between 7 and 8 is the Makefile for mingw which now define: -D_USE_32BIT_TIME_T According to the commit log, this change was fixing winxp build, but apparently it break my windows 8 64bit ones.. (may be windows 7 64 bit, I didn't try) Someone know how to test for windows version from the makefile and from which version this defined is not needed ? Meanwhile, I'll try to experiment when I will have a chance. thanks -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
2013/10/10 Martin Gagnon eme...@gmail.com: It happens that the only difference between 7 and 8 is the Makefile for mingw which now define: -D_USE_32BIT_TIME_T This define should only be used for a 32-bit build, never for 64-bit, so this is indeed a bug. I'll have a look how to fix this. Thanks! Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
2013/10/10 Jan Nijtmans jan.nijtm...@gmail.com: 2013/10/10 Martin Gagnon eme...@gmail.com: It happens that the only difference between 7 and 8 is the Makefile for mingw which now define: -D_USE_32BIT_TIME_T This define should only be used for a 32-bit build, never for 64-bit, so this is indeed a bug. I'll have a look how to fix this. Should be fine now: http://fossil-scm.org/index.html/info/d66cfb164f Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Breakthrough! [was Re: missing branch tag (?)]
On Thu, Oct 10, 2013 at 7:31 PM, B Harder brad.har...@gmail.com wrote: Breakthrough! I have a minimal(ish) example of a repo that is broken: Take the attached (broken.fsl, 62K) repo, co [vendor], and try to merge [trunk]. i end up with: http://www.wanderinghorse.net/tmp/brad-broke.png which is what i would expect? (Of course i had to lie and say i was user bch.) This is fossil version 1.27 [4137f4cda9] 2013-09-26 08:09:03 UTC -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Breakthrough! [was Re: missing branch tag (?)]
On Thu, Oct 10, 2013 at 7:54 PM, Stephan Beal sgb...@googlemail.com wrote: This is fossil version 1.27 [4137f4cda9] 2013-09-26 08:09:03 UTC What led up to that... stephan@tiny:~/tmp/foo$ f co vendor vendor/x vendor/y vendor/z stephan@tiny:~/tmp/foo$ fst repository: /home/stephan/tmp/foo/../broken.fsl local-root: /home/stephan/tmp/foo/ config-db:/home/stephan/.fossil checkout: 15b9492ca5753743b6840a0ad27bc101539e0f5c 2013-10-10 17:41:40 UTC parent: 0560bf65a911ecf3c56ab8357e37b17a472e 2013-10-10 17:37:20 UTC merged-into: 823ef84391f087a1e0b1db29e3f67798b453e2fd 2013-10-10 17:43:32 UTC merged-into: 0a37e5f9ca3d45ae8de84490c65bb66b39c8d5e5 2013-10-10 17:42:57 UTC tags: vendor comment: vendor code (user: bch) stephan@tiny:~/tmp/foo$ f time === 2013-10-10 === 17:44:09 [af3c0cf56a] trunk changes (user: bch tags: trunk) 17:43:32 [823ef84391] *MERGE* merge [vendor] to [trunk] (user: bch tags: trunk) 17:42:57 [0a37e5f9ca] *MERGE* merge [vendor] to [feature] (user: bch tags: feature) 17:42:04 [319b2aab08] additional changes (user: bch tags: trunk) 17:41:40 [15b9492ca5] *CURRENT* vendor code (user: bch tags: vendor) 17:40:53 [676e310103] Edit [0560bf65a911ecf3]: Add tag origin. (user: bch) 17:39:37 [41607806fa] feature change (user: bch tags: feature) 17:38:23 [22d713ee40] *BRANCH* change on trunk (user: bch tags: trunk) 17:38:06 [7cbfa2a065] initial trunk ci (user: bch tags: trunk) 17:37:20 [0560bf65a9] *BRANCH* initial empty check-in (user: bch tags: trunk, origin) stephan@tiny:~/tmp/foo$ f merge trunk ADDED a ADDED b ADDED c fossil undo is available to undo changes to the working checkout. stephan@tiny:~/tmp/foo$ fst repository: /home/stephan/tmp/foo/../broken.fsl local-root: /home/stephan/tmp/foo/ config-db:/home/stephan/.fossil checkout: 15b9492ca5753743b6840a0ad27bc101539e0f5c 2013-10-10 17:41:40 UTC parent: 0560bf65a911ecf3c56ab8357e37b17a472e 2013-10-10 17:37:20 UTC merged-into: 823ef84391f087a1e0b1db29e3f67798b453e2fd 2013-10-10 17:43:32 UTC merged-into: 0a37e5f9ca3d45ae8de84490c65bb66b39c8d5e5 2013-10-10 17:42:57 UTC tags: vendor comment: vendor code (user: bch) ADDED_BY_MERGE a ADDED_BY_MERGE b ADDED_BY_MERGE c MERGED_WITH af3c0cf56a37b79a7d46b3a1a940a1f2dfd2df19 stephan@tiny:~/tmp/foo$ f com -m foo --user bch New_Version: 2487f5846909ec0b33dfc00cdf61f7c0bd8468bd stephan@tiny:~/tmp/foo$ fst repository: /home/stephan/tmp/foo/../broken.fsl local-root: /home/stephan/tmp/foo/ config-db:/home/stephan/.fossil checkout: 2487f5846909ec0b33dfc00cdf61f7c0bd8468bd 2013-10-10 17:50:21 UTC parent: 15b9492ca5753743b6840a0ad27bc101539e0f5c 2013-10-10 17:41:40 UTC merged-from: af3c0cf56a37b79a7d46b3a1a940a1f2dfd2df19 2013-10-10 17:44:09 UTC tags: vendor comment: foo (user: bch) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Breakthrough! [was Re: missing branch tag (?)]
hrmmm... interesting. I was getting no common ancestor. I closed that repo to mail it. You did you testing (successfully). I re-opened the repo to replicate my results, and in fact it worked fine. If you (anybody) have the time, would you create a repo and go through the ~10 steps manually and see what happens? What I was concentrating on is: [vendor] is branched off initial emtpy ci [feature] is branched off [trunk] [feature] -[vendor] before [trunk] - [vendor] [feature] - [trunk] then fails w/ no common ancestors Now, out of curiosity I'm going to close/open my test/clone problem repo. On 10/10/13, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 10, 2013 at 7:31 PM, B Harder brad.har...@gmail.com wrote: Breakthrough! I have a minimal(ish) example of a repo that is broken: Take the attached (broken.fsl, 62K) repo, co [vendor], and try to merge [trunk]. i end up with: http://www.wanderinghorse.net/tmp/brad-broke.png which is what i would expect? (Of course i had to lie and say i was user bch.) This is fossil version 1.27 [4137f4cda9] 2013-09-26 08:09:03 UTC -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Breakthrough! [was Re: missing branch tag (?)]
closed/opened my more complex real-world problem repo and problem still exists. On 10/10/13, B Harder brad.har...@gmail.com wrote: hrmmm... interesting. I was getting no common ancestor. I closed that repo to mail it. You did you testing (successfully). I re-opened the repo to replicate my results, and in fact it worked fine. If you (anybody) have the time, would you create a repo and go through the ~10 steps manually and see what happens? What I was concentrating on is: [vendor] is branched off initial emtpy ci [feature] is branched off [trunk] [feature] -[vendor] before [trunk] - [vendor] [feature] - [trunk] then fails w/ no common ancestors Now, out of curiosity I'm going to close/open my test/clone problem repo. On 10/10/13, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 10, 2013 at 7:31 PM, B Harder brad.har...@gmail.com wrote: Breakthrough! I have a minimal(ish) example of a repo that is broken: Take the attached (broken.fsl, 62K) repo, co [vendor], and try to merge [trunk]. i end up with: http://www.wanderinghorse.net/tmp/brad-broke.png which is what i would expect? (Of course i had to lie and say i was user bch.) This is fossil version 1.27 [4137f4cda9] 2013-09-26 08:09:03 UTC -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Breakthrough! [was Re: missing branch tag (?)]
WARNING - no common ancestor: somefile WARNING - no common ancestor: someotherfile WARNING - no common ancestor: anotherfile ... On 10/10/13, B Harder brad.har...@gmail.com wrote: closed/opened my more complex real-world problem repo and problem still exists. On 10/10/13, B Harder brad.har...@gmail.com wrote: hrmmm... interesting. I was getting no common ancestor. I closed that repo to mail it. You did you testing (successfully). I re-opened the repo to replicate my results, and in fact it worked fine. If you (anybody) have the time, would you create a repo and go through the ~10 steps manually and see what happens? What I was concentrating on is: [vendor] is branched off initial emtpy ci [feature] is branched off [trunk] [feature] -[vendor] before [trunk] - [vendor] [feature] - [trunk] then fails w/ no common ancestors Now, out of curiosity I'm going to close/open my test/clone problem repo. On 10/10/13, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 10, 2013 at 7:31 PM, B Harder brad.har...@gmail.com wrote: Breakthrough! I have a minimal(ish) example of a repo that is broken: Take the attached (broken.fsl, 62K) repo, co [vendor], and try to merge [trunk]. i end up with: http://www.wanderinghorse.net/tmp/brad-broke.png which is what i would expect? (Of course i had to lie and say i was user bch.) This is fossil version 1.27 [4137f4cda9] 2013-09-26 08:09:03 UTC -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to fix links to wiki pages if project name is changed?
On Thu, Oct 10, 2013 at 8:19 PM, j. van den hoff veedeeh...@googlemail.comwrote: seems that either all wiki pages are viewable w/o login or none at all. i.e. there is no finer-grained access control (e.g. on a per-wiki page basis). is this right? Correct. while access-control on a per-page basis might be overkill it would be rather nice to have a distinct landing/welcome page which could be _always_ world-viewable while all the confidental content (in case there is such content) could go to other wiki pages. is there a way to achieve this or might this be a useful feature? +1. i _think_ you can achieve that now by setting one of the embedded docs as your home page and leaving the wikis private, but i haven't tried that. Embedded docs might follow the same access rules as the wiki (haven't checked). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to fix links to wiki pages if project name is changed?
On Thu, Oct 10, 2013 at 2:19 PM, j. van den hoff veedeeh...@googlemail.comwrote: thanks for clarification. another question which comes up for me for the first time: it seems that either all wiki pages are viewable w/o login or none at all. i.e. there is no finer-grained access control (e.g. on a per-wiki page basis). is this right? while access-control on a per-page basis might be overkill it would be rather nice to have a distinct landing/welcome page which could be _always_ world-viewable while all the confidental content (in case there is such content) could go to other wiki pages. is there a way to achieve this or might this be a useful feature? Under Admin/Access there is an entry box marked Public Pages that gives public access to an otherwise locked-down Fossil site, based on glob patterns. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to fix links to wiki pages if project name is changed?
On Thu, Oct 10, 2013 at 8:21 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 10, 2013 at 8:19 PM, j. van den hoff veedeeh...@googlemail.com wrote: seems that either all wiki pages are viewable w/o login or none at all. i.e. there is no finer-grained access control (e.g. on a per-wiki page basis). is this right? Correct. For the archives: Correct == Incorrect. Mixing embedded docs and wiki might still be an option, as well, but i sounds like the glob approach will work for you. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Breakthrough! [was Re: missing branch tag (?)]
Thus said B Harder on Thu, 10 Oct 2013 11:03:59 -0700: I was getting no common ancestor. I too get the warning when using your broken.fsl if I merge into the feature branch from trunk: $ f mer 823ef8 WARNING - no common ancestor: a WARNING - no common ancestor: b WARNING - no common ancestor: c However, I notice that I don't get it if I merge with the trunk just prior to that commit: $ f merge 319b2a UPDATE c fossil undo is available to undo changes to the working checkout. 823ef8 has a merge in from the vendor branch which was forked prior to adding a, b, and c to the trunk. It looks like when the vendor branch was merged into trunk, it somehow lost the ancestry of a, b, and c? I'm not sure if this is correct behavior or not. Andy -- TAI64 timestamp: 40005256f2cb ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to fix links to wiki pages if project name is changed?
On Thu, 10 Oct 2013 20:24:35 +0200, Richard Hipp d...@sqlite.org wrote: On Thu, Oct 10, 2013 at 2:19 PM, j. van den hoff veedeeh...@googlemail.comwrote: thanks for clarification. another question which comes up for me for the first time: it seems that either all wiki pages are viewable w/o login or none at all. i.e. there is no finer-grained access control (e.g. on a per-wiki page basis). is this right? while access-control on a per-page basis might be overkill it would be rather nice to have a distinct landing/welcome page which could be _always_ world-viewable while all the confidental content (in case there is such content) could go to other wiki pages. is there a way to achieve this or might this be a useful feature? Under Admin/Access there is an entry box marked Public Pages that gives public access to an otherwise locked-down Fossil site, based on glob patterns. I will check that out. thanks for the tip. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to fix links to wiki pages if project name is changed?
On Thu, 10 Oct 2013 20:24:35 +0200, Richard Hipp d...@sqlite.org wrote: On Thu, Oct 10, 2013 at 2:19 PM, j. van den hoff veedeeh...@googlemail.comwrote: thanks for clarification. another question which comes up for me for the first time: it seems that either all wiki pages are viewable w/o login or none at all. i.e. there is no finer-grained access control (e.g. on a per-wiki page basis). is this right? while access-control on a per-page basis might be overkill it would be rather nice to have a distinct landing/welcome page which could be _always_ world-viewable while all the confidental content (in case there is such content) could go to other wiki pages. is there a way to achieve this or might this be a useful feature? Under Admin/Access there is an entry box marked Public Pages that gives public access to an otherwise locked-down Fossil site, based on glob patterns. if a quick answer is possible and before I mess something up here during testing it myself: presuming I do want to make only the default 'landing page' viewable without login, I could set the glob pattern just to /home right? what exactly is the interaction with the default privilege which is set to u (reader) by default which in turn seems to indicate the capability to read the (whole?) wiki. should I simply set the default privilege to the empty string? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
On Thu, Oct 10, 2013 at 04:39:03PM +0200, Jan Nijtmans wrote: 2013/10/10 Jan Nijtmans jan.nijtm...@gmail.com: 2013/10/10 Martin Gagnon eme...@gmail.com: It happens that the only difference between 7 and 8 is the Makefile for mingw which now define: -D_USE_32BIT_TIME_T This define should only be used for a 32-bit build, never for 64-bit, so this is indeed a bug. I'll have a look how to fix this. Should be fine now: http://fossil-scm.org/index.html/info/d66cfb164f Still doesn't work, but I get different error: -- In file included from c:/msys/mingw-x64/mingw64/x86_64-w64-mingw32/include/crtdefs.h:10:0, from c:/msys/mingw-x64/mingw64/x86_64-w64-mingw32/include/assert.h:15, from src/captcha.c:22: c:/msys/mingw-x64/mingw64/x86_64-w64-mingw32/include/_mingw.h:456:2: error: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 ^ make: *** [wbld/captcha.o] Error 1 -- Regards.. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
On Thu, Oct 10, 2013 at 04:39:03PM +0200, Jan Nijtmans wrote: 2013/10/10 Jan Nijtmans jan.nijtm...@gmail.com: 2013/10/10 Martin Gagnon eme...@gmail.com: It happens that the only difference between 7 and 8 is the Makefile for mingw which now define: -D_USE_32BIT_TIME_T This define should only be used for a 32-bit build, never for 64-bit, so this is indeed a bug. I'll have a look how to fix this. Should be fine now: http://fossil-scm.org/index.html/info/d66cfb164f Regards, Jan Nijtmans Finally, I found that your change in config.h fix the problem on some source files, but some source files include some system header files before the config.h (some even doesn't include config.h). I tried to fix this by making sure that every source include config.h before any other includes, but I got stuck when I go the error from sqlite3.c Probalby we need solution other than the #undef in the config.h... what do you think ? -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
