Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
FreeBSD build
afb:
--- 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?
--- End quote ---
It wouldn't "abort", would it ? But run with REVISION=0 and DATE="", yes ?
thomas:
--- Quote ---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 ?
--- End quote ---
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.
--- Quote ---The Fedora Core package already patches out autorevision entirelly, for instance (and writes out the code for src/sdk/autorevision.h itself)
--- End quote ---
Well, that's bad, very bad.
--- Quote ---I don't think that the build should require svn, if all the info is there.
--- End quote ---
It should not and it does not.
--- Quote ---It wouldn't "abort", would it ? But run with REVISION=0 and DATE="", yes ?
--- End quote ---
Well, I don't know ;)
That's what autorevision does. No need to add anything in configure for that effect.
afb:
--- 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.
--- End quote ---
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 addition will be great too.
--- Quote ---
--- Quote ---The Fedora Core package already patches out autorevision entirelly, for instance (and writes out the code for src/sdk/autorevision.h itself)
--- End quote ---
Well, that's bad, very bad.
--- End quote ---
So I was trying to make it better, by providing a means to avoid it.
--- Quote ---
--- Quote ---It wouldn't "abort", would it ? But run with REVISION=0 and DATE="", yes ?
--- End quote ---
Well, I don't know ;)
That's what autorevision does. No need to add anything in configure for that effect.
--- End quote ---
Except to make it / keep it working the same way as autorevision.
thomas:
--- Quote from: afb on November 14, 2006, 10:59:46 am ---(ignoring for a moment that MinGW does have autotools)
--- End quote ---
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 :)
--- Quote ---And autotools is good for generating e.g. codeblocks.spec and codeblocks.plist, unless you wanted to do those in C++ as well ?
--- End quote ---
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.
--- Quote ---On a side note, I think the wx-config.cpp addition will be great too.
--- End quote ---
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)?
afb:
--- 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)
--- End quote ---
MinGW does not have automake, you can use automake with MSYS though.
--- End quote ---
I meant MSYS, sorry... Actually I meant "a real shell" :-)
--- Quote ---However, we don't seriously consider building Code::Blocks with MSYS, do we :)
--- End quote ---
Why not ? I don't see why it shouldn't (eventually) work
--- Quote ---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 :)
--- End quote ---
You don't, you write a program... C++, Perl, whatever. (no argument there)
--- Quote ---
--- Quote ---And autotools is good for generating e.g. codeblocks.spec and codeblocks.plist, unless you wanted to do those in C++ as well ?
--- End quote ---
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.
--- End quote ---
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.
--- Quote ---
--- Quote ---On a side note, I think the wx-config.cpp addition will be great too.
--- End quote ---
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)?
--- End quote ---
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)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version