Hello, I've been attempting to get CodeBlocks to build on freebsd, here are my specs:
* FreeBSD 6.1 i386
* wxWidgets 2.6.3
* CB SVN rev 3207
I got as far as compiling it, but it stopped halfway, the error is:
"In file included from sqplus.h:18, from SqPlus.cpp:1: /usr/include/malloc.h:3:2: error "<malloc.h> has been replaced by <stdlib.h>"
*** Error code 1
...
Is this just a problem with the current revision or is my build messed up in some way? :?
Open that file and change "#include <malloc.h>" to "#include <cstdlib>".
And be sure to tell us if it worked or not so we can make the change in our repository...
stdlib.h is already being included, so I think all that is needed is to avoid including the non-standard malloc.h header on the FreeBSD platform ?
#ifndef _SQ_PLUS_H_
#define _SQ_PLUS_H_
#include <stdlib.h>
#ifdef __APPLE__
#include <malloc/malloc.h>
#elif !defined(__FREEBSD__)
#include <malloc.h>
#endif
#include <memory.h>
Something like that, anyway. HAVE_MALLOC_H is also nice, but requires config.h first. And we might not want to introduce that in the SqPlus sources ? (and this bug should go upstream)
Quote from: mandrav on November 13, 2006, 02:06:01 PM
Open that file and change "#include <malloc.h>" to "#include <cstdlib>".
And be sure to tell us if it worked or not so we can make the change in our repository...
that fixed it, but I am now having trouble with this:
autorevision.h:14: error: 'encoding' was not declared in this scope
...
Quote from: Russell on November 13, 2006, 09:02:44 PM
autorevision.h:14: error: 'encoding' was not declared in this scope
What does your src/sdk/autorevision.h look like ?
(sounds like something went wrong, generating it)
/*encoding="utf-8"?>*/
#ifndef AUTOREVISION_H
#define AUTOREVISION_H
#include <wx/string.h>
#define SVN_REVISION "encoding="utf-8"?>"
#define SVN_DATE "<entry"
namespace autorevision
{
const unsigned int svn_revision = encoding="utf-8"?>;
const wxString svnRevision(_T("encoding="utf-8"?>"));
}
#endif
I did notice that at the start of the build, it mentioned something about a locale, not entirely sure if thats what it would be.
I'm building a unicode version by the way
In case you wondered, that looks... wrong. :-P
SVN_REVISION is supposed to be the revision number (like "3209")
and SVN_DATE a date... (like "2006-11-13 14:10:27", for instance)
Quote from: afb on November 13, 2006, 10:16:21 PM
In case you wondered, that looks... wrong. :-P
That's right - it's wrong. The reason is that he isn't using a recent svn (>version 1.2). This is no longer supported. I suggest you (Russell) upgrade your svn before continuing...
If that is not an option to you you could also try to downgrade the sources of autorevision (only this) to at least revision 2831.
With regards, Morten.
We so need to overhaul these revision scripts, they're getting long in the tooth...
Requiring a certain version or locale of Subversion without telling is not very nice.
At least they should be able to politely tell you when things are going totally wrong ?
svn --version --quiet
Quote from: Russell on November 13, 2006, 09:42:56 PM
I did notice that at the start of the build, it mentioned something about a locale, not entirely sure if thats what it would be.
BTW; Where does "svn" live on FreeBSD ?
Quote from: afb on November 13, 2006, 10:53:52 PMWe so need to...
No need to do anything, these are old issues. It's just that we get the same issue posted again and again because the working copy is still not updated.
You get that kind of problem with the "newer old"
autorevision if you are using an old client and don't have it available in PATH, so the fallback
entries parsing kicks in (and fails because it is an unsupported format).
The "old old" version of
autorevision would work fine in this scenario, but it would fail with a newer version.
Yiannis still needs to commit the most recent version. That one should have no such problems any more, as it has no fallback path at all any more.
What I meant is that it is getting somewhat tedious to see the same old bugs with revision/autorevision and make dist/tarball over and over again, but I know I don't have to tell you that.
What did you think about fixing update_revision.sh / using autotools, by the way ? We should make that shell script and autorevision.cpp work the same way, in order to avoid confusion...
Quote from: thomas on November 13, 2006, 11:08:58 PM
Quote from: afb on November 13, 2006, 10:53:52 PMWe so need to...
No need to do anything, these are old issues. [...]
Hey, another idea: Why don't we put the sources out our prefered svn version into build_tools... ?! *lol* :lol: :mrgreen: ;-)
With regards, (not to be taken seriously) Morten.
Quote from: afb on November 13, 2006, 11:13:57 PMWhat did you think about fixing update_revision.sh / using autotools, by the way ? We should make that shell script and autorevision.cpp work the same way, in order to avoid confusion...
Sorry, not having a clear head yet today (never talk to me before 10...).
You mean to modify the script you wrote that copies the generated header into the release tarball? Or do you mean to add a line to
configure so it aborts when it doesn't find svn?
Quote from: thomas on November 14, 2006, 09:09:08 AM
You mean to modify the script you wrote that copies the generated header into the release tarball? Or do you mean to add a line to configure so it aborts when it doesn't find svn?
I mean modify the build scripts so that autotools would generate both revision.m4 and src/sdk/autorevision.h from the current SVN info, either cached in a "dist" tarball or retrieved from the "svn" client ?
The Fedora Core package already patches out autorevision entirelly,
for instance (and writes out the code for src/sdk/autorevision.h itself)
I don't think that the build should require svn, if all the info is there.
Quote from: thomas on November 14, 2006, 09:09:08 AM
Or do you mean to add a line to configure so it aborts when it doesn't find svn?
It wouldn't "abort", would it ? But run with REVISION=0 and DATE="", yes ?
QuoteI mean modify the build scripts so that autotools would generate both revision.m4 and src/sdk/autorevision.h from the current SVN info, either cached in a "dist" tarball or retrieved from the "svn" client ?
For "dist" tarballs, the revision should already be "coded in". Generating the header file during
make dist and including it in the tarball makes sense.
However, the reason why
autorevision exists at all is that one tool should do the same on all platforms instead of a dozen different scripts for a dozen platforms, each doing something else and each having to be maintained.
The same executable does the same thing under Windows (where you have no such thing as autotools) and Linux, or whatever OS. It's not like I would not have preferred 2 lines of script in the first place, but that just doesn't work out.
QuoteThe Fedora Core package already patches out autorevision entirelly, for instance (and writes out the code for src/sdk/autorevision.h itself)
Well, that's bad, very bad.
QuoteI don't think that the build should require svn, if all the info is there.
It should not and it does not.
QuoteIt wouldn't "abort", would it ? But run with REVISION=0 and DATE="", yes ?
Well, I don't know ;)
That's what
autorevision does. No need to add anything in
configure for that effect.
Quote from: thomas on November 14, 2006, 10:51:23 AM
However, the reason why autorevision exists at all is that one tool should do the same on all platforms instead of a dozen different scripts for a dozen platforms, each doing something else and each having to be maintained.
The same executable does the same thing under Windows (where you have no such thing as autotools) and Linux, or whatever OS. It's not like I would not have preferred 2 lines of script in the first place, but that just doesn't work out.
I think autorevision.cpp is a great fallback for Windows (ignoring for a moment that MinGW does have autotools), but it will only be needed if src/sdk/autorevision.h is missing ? And autotools is good for generating e.g. codeblocks.spec and codeblocks.plist, unless you wanted to do those in C++ as well ?
On a side note, I think the wx-config.cpp (http://wxconfig.googlepages.com/) addition will be great too.
Quote
QuoteThe Fedora Core package already patches out autorevision entirelly, for instance (and writes out the code for src/sdk/autorevision.h itself)
Well, that's bad, very bad.
So I was trying to make it better, by providing a means to avoid it.
QuoteQuoteIt wouldn't "abort", would it ? But run with REVISION=0 and DATE="", yes ?
Well, I don't know ;)
That's what autorevision does. No need to add anything in configure for that effect.
Except to make it / keep it working the same way as autorevision.
Quote from: afb on November 14, 2006, 10:59:46 AM(ignoring for a moment that MinGW does have autotools)
MinGW does not have automake, you can use automake with MSYS though. However, we don't seriously consider building Code::Blocks with MSYS, do we :)
MinGW has no such thing as
sed or any other non-compiler-non-linker tool coming with a standard installation. How do you implement parsing
svn's output and writing out a header file with
gcc,
as, and
ld being your only tools? Enter
autorevision. That was the whole reason why it ever came into existence :)
QuoteAnd autotools is good for generating e.g. codeblocks.spec and codeblocks.plist, unless you wanted to do those in C++ as well ?
Meknows nothing of specs and plists, but since these are RPM stuff, so Linux only, autotools is of course the right thing to use for that.
QuoteOn a side note, I think the wx-config.cpp (http://wxconfig.googlepages.com/) addition will be great too.
Great for what? I don't understand what we should need it for (apart from the fact that I was told it does not work)?
Quote from: thomas on November 14, 2006, 11:30:14 AM
Quote from: afb on November 14, 2006, 10:59:46 AM(ignoring for a moment that MinGW does have autotools)
MinGW does not have automake, you can use automake with MSYS though.
I meant MSYS, sorry... Actually I meant "a real shell" :-)
QuoteHowever, we don't seriously consider building Code::Blocks with MSYS, do we :)
Why not ? I don't see why it shouldn't (eventually) work
QuoteMinGW has no such thing as sed or any other non-compiler-non-linker tool coming with a standard installation. How do you implement parsing svn's output and writing out a header file with gcc, as, and ld being your only tools? Enter autorevision. That was the whole reason why it ever came into existence :)
You don't, you write a program... C++, Perl, whatever. (no argument there)
QuoteQuoteAnd autotools is good for generating e.g. codeblocks.spec and codeblocks.plist, unless you wanted to do those in C++ as well ?
Meknows nothing of specs and plists, but since these are RPM stuff, so Linux only, autotools is of course the right thing to use for that.
They are not RPM/Linux only, they are just text files with a @REVISION@ value that wants to get replaced ?
i.e. codeblocks.spec.in => codeblocks.spec, codeblocks.plist.in => codeblocks.plist, etc. etc.
QuoteQuoteOn a side note, I think the wx-config.cpp (http://wxconfig.googlepages.com/) addition will be great too.
Great for what? I don't understand what we should need it for (apart from the fact that I was told it does not work)?
Great so that I can use the same
`wx-config --cxxflags --libs` everywhere, without having to write one thing for the GNU tools, one thing for Windows and one thing for Mac OS X ? Too bad that you say it doesn't work, though. (I was really hoping for a solution to my current wxWidgets-on-Windows-without-MSYS problem)
Quote from: thomas on November 14, 2006, 11:30:14 AM
Quote from: afb on November 14, 2006, 10:59:46 AM(ignoring for a moment that MinGW does have autotools)
MinGW does not have automake, you can use automake with MSYS though. However, we don't seriously consider building Code::Blocks with MSYS, do we :)
MinGW has no such thing as sed or any other non-compiler-non-linker tool coming with a standard installation. How do you implement parsing svn's output and writing out a header file with gcc, as, and ld being your only tools? Enter autorevision. That was the whole reason why it ever came into existence :)
QuoteAnd autotools is good for generating e.g. codeblocks.spec and codeblocks.plist, unless you wanted to do those in C++ as well ?
Meknows nothing of specs and plists, but since these are RPM stuff, so Linux only, autotools is of course the right thing to use for that.
QuoteOn a side note, I think the wx-config.cpp (http://wxconfig.googlepages.com/) addition will be great too.
Great for what? I don't understand what we should need it for (apart from the fact that I was told it does not work)?
Off-topic and despite I agree on your entire post, can you tell me who told you and when that "the fact that I was told it does not work"?
Thanks.
Here was the updated shell code: (to use XML as the first option)
LANG=C
export LANG
if svn --xml info >/dev/null 2>&1; then
REV=`svn --xml info | tr -d '\r\n' | sed -e 's/.*<commit.*revision="\([0-9]*\)".*<\/commit>.*/\1/'`
LCD=`svn --xml info | tr -d '\r\n' | sed -e 's/.*<commit.*<date>\([0-9\-]*\)\T\([0-9\:]*\)\..*<\/date>.*<\/commit>.*/\1 \2/'`
elif svn --version --quiet >/dev/null 2>&1; then
REV=`svn info | grep "^Revision:" | cut -d" " -f2`
LCD=`svn info | grep "^Last Changed Date:" | cut -d" " -f4,5`
else
REV=0
LCD=""
fi
Just for discussion reference, it will be posted elsewhere as well.
Quote from: afb on November 14, 2006, 12:45:44 PMHere was the updated shell code: (to use XML as the first option)
Looks like it should work fine.
Quotecan you tell me who told you and when
Who: Someone who I believe. :) I'm don't remember for sure who said it (there are 3 possible candidates, and I shan't point at someone without being 100% sure), but out of the three people who are in question, I'd believe anyone.
When: Don't know... a few weeks back? Maybe 2, maybe 3? Would have to search my messenger logs to know the date.
Quote from: thomas on November 14, 2006, 01:00:06 PM
Who: Someone who I believe. :)
In any case I guess it's not
Quote from: tiwag on October 18, 2006, 05:54:12 PM
i used your wx-config-win too and it works very well indeed.
there is only one big problem: codecompletion isn't working when
you setup your cb-project using wx-config, because the path to the
include files isn't know for CB during editing.
nor
Quote from: rjmyst3 on October 18, 2006, 08:19:51 PM
I've also been using wx-config-win of late, and it works very well - nice work!
I was just thinking how nice it would be to have a wizard using it ... :D
at least.
Quote from: thomas on November 14, 2006, 01:00:06 PM
I'm don't remember for sure who said it (there are 3 possible candidates, and I shan't point at someone without being 100% sure), but out of the three people who are in question, I'd believe anyone.
Me and tiwag have tested it not more than enough but fairly enough, so it would be nice whoever said it, can submit any issue found to the issue tracker, it will be much appreciated;
And here was src/sdk/autorevision.h.in:
/*@REVISION@*/
#ifndef AUTOREVISION_H
#define AUTOREVISION_H
#include <wx/string.h>
#define SVN_REVISION "@REVISION@"
#define SVN_DATE "@DATE@"
namespace autorevision
{
const unsigned int svn_revision = @REVISION@;
const wxString svnRevision(_T("@REVISION@"));
}
#endif