Hi. I've been thinking, there is any way (either from Windows Shell or C::B side) to support backticks in C::B?
For example, I'm thinking of backticks in the Linker project section, calling something like `wx-config --libs`. In Bourne Shell (Linux) systems that's pretty common.
So, how could we use something like that, as `sdl-config.bat --cflags` in Windows?
The solution I'm thinking, is simulating support for backticks from the C::B side, as I don't think it will be possible from the Windows Shell side.
What do you think?
It would be possible to simulate this simply by invoking cmd and capturing stdout. Under Linux, you don't need to do anything, it is a shell feature anyway.
However, I don't think this is a good idea for several reasons, most importantly for this one:
Variable expansion may run many times.
Invoking a shell is a prohibitively expensive operation when it may happen many times, at all times. Also, backticks may have side effects (a script may actually write out some config to the disk, for example) which may not have to be executed many times. You are not in control of this, because variable expansion is done many times (for example when opening the compiler options dialog).
That could be easily added.
But the point is what would you achieve? I mean, someone has to write this sdl-config.bat and it will not be universal, i.e. "take this batch file and you 're done"...
If you explain your thoughts about this, we might find some better way to do this (like using scripting for example).
Well, my main concern is to make cbp projects more or less the same for all platforms, thus alivianating the problem:
Quote from: Takeshi Miya on January 16, 2006, 08:32:22 AM
Sadly, you will have to create a cbp with wx-config and all that stuff.
It's a real pity that the projects files can't be multi-platform (when using any library other than STL).
However I've been thinking, and it seems there isn't any easy solution for that. The main problem is the configure (and the detection of library/include paths) stuff.
As you know, autofriends are not multiplatform (so in Windows they can be used only in a *nix like environment like msys/cygwin, which are very uncommon). But, they are very popular in linux land.
So in Windows:Automake is currently perfectly replaced by C::B own build system.
Autoconf/Libtool is almost inexistant, but Global Variables can alivianate a bit the problem.
However, a tool I didn't knew, called
pkg-config, which is pretty common in Linux land, and not-so-common on WIndows, but it works outside msys/cygwin. can really alivianate most of this.
Quoting:
Quote
pkg-config is a helper tool used when compiling applications and libraries. It helps you insert the correct compiler options on the command line so an application can use gcc -o test test.c `pkg-config --libs --cflags glib-2.0` for instance, rather than hard-coding values on where to find glib (or other libraries). It is language-agnostic, so it can be used for defining the location of documentation tools, for instance.
pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows. It does not require anything but a reasonably well working C compiler and a C library
So, my current thoughts is something like mixing
pkg-config with
Global Variables. (Having values for Global Variables being read from pkg-config database perhaps).
Quote from: Takeshi Miya on January 16, 2006, 09:16:06 AMAs you know, autofriends are not multiplatform (so in Windows they can be used only in a *nix like environment like msys/cygwin, which are very uncommon). But, they are very popular in linux land.
Luckily, we have somebody working on autotools import now, so that will solve that issue. :)
Yes, that issue (really? who? :D nice to hear).
But my main concern still remains, for projects written from scratch (without any use of autotools), what I'm saying is still valid (pkg-config is not autotools, and can be used).
Quote from: Takeshi Miya on January 16, 2006, 09:30:14 AMreally? who? :D nice to hear
You.
Quote from: Takeshi Miya on January 10, 2006, 07:08:48 PM
So I'm thinking if we can do a simple "configure"-like system [...]
Quote from: Takeshi Miya on January 10, 2006, 08:10:46 PM
Ok, I wanted to know if the idea was welcomed or not, so I could think next.
Well, I'm trying to attack the current problem of "cbp projects are very different from linux to windows".
I'm yet not convinced by any existant or not existant solution, so there isn't any final word.
Anyways I (researched) more, and maybe pkg-config could suffice, for now (moreover it's standard on linux).
Just a side note: simple "configure"-like system idea is very very far away from autotools import idea.
So, any thoughts on what I'm talking on #3?
Quote from: Takeshi Miya on January 16, 2006, 10:05:13 AM
Just a side note: simple "configure"-like system idea is very very far away from autotools import idea.
Well, in the other thread (out of which I only quoted two lines), you were referring to "Any project that uses a configure script in linux (SDL, GTK, wx, QT, etc), and even personal projects" and "the concept "./configure" in Windows".
This pretty much sounded like "autotools import" to me. Personally, I was amazed then, and I still am, because I don't have even the faintest idea how one could implement such a thing.
Quote from: thomas on January 16, 2006, 10:43:15 AM
This pretty much sounded like "autotools import" to me.
Sorry for the confusion, to clear it up:
"./configure" != simple "./configure-like".
Quote from: thomas on January 16, 2006, 10:43:15 AM
Personally, I was amazed then, and I still am, because I don't have even the faintest idea how one could implement such a thing.
lol, neither I do. Parsing
m4 in heavy cryptic 700KB configure scripts is something that we never live enough to see, probably. :lol:
Now that that is clear (I have to learn english), what about
pkg-config ~
global variables interaction ?
If it does not break anything, sure.
I'm asking because I'm kind of lost. My 2nd approach was to use `pkg-config --libs` kind of things in Windows. That's why I asked first if backticks was feasible.
If it's not feasible, or another (better) approach can be used (trough global/compiler/project variables, or any other kind), great.
But yet, something like support for backticks will be more user-friendly to users coming from other *nix IDEs (KDevelop/Anjuta/etc), wanting to use his/her cbp in windows.
Well you see, backticks are possible (and not hard to implement). But the problem is that they may get executed many times (at least once while the project is loaded and at least twice per build, and every time you open the build options dialog).
You would not want to wait for 20 seconds each time when opening a project or when changing build options just because someone had the brilliant idea to put very-complex-script into backticks, would you? Likewise, you would not want modify-and-delete-files-script to run every time you open a dialog.
Here you go. Revision 1766.
Let us know of your progress :)
lol, I'm on Ubuntu 64 from 5 days ago (yes, I finally could get it working on this pc -note: never buy a motherboard with an ati chipset-), and not rebooted the pc in Windows from that day. :)
I couldn't compile C::B on it yet (lot's of AngelScript errors, and it isn't #ifdef'ed...).
Now I'll reboot to that thing called Windows.
I'm going to check out if it's still alive :P
Quote from: Takeshi Miya on January 16, 2006, 12:35:42 PM
I couldn't compile C::B on it yet (lot's of AngelScript errors, and it isn't #ifdef'ed...).
If you fix them, please send me a patch. It 'd be nice to make AngelScript 64bit compatible :)
No problem, just I don't know how to fix them properly (commenting some offending lines makes it compile more).
Because I don't know this kind of things (AngelScript):
currentObject = (void*)(int(currentObject) + sysFunc->baseOffset);
error: cast from 'void*' to 'int' loses precision
Or wxAUI (for what is a random string created??):
// if the pane's name identifier is blank, create a random string
if (pinfo.name.IsEmpty())
{
pinfo.name.Printf(wxT("%08x%08x%08x%08x"),
(unsigned int)pinfo.window, (unsigned int)time(NULL),
(unsigned int)clock(), m_panes.GetCount());
}
error: cast from 'wxWindow*' to 'unsigned int' loses precision
More compiler errors (castings):
error: invalid conversion from 'void* (*)(size_t)throw ()' to 'void* (*)(asUINT)'
And linker errors (probably related to x86 optimizations of calling conventions for system functions?):
libcodeblocks.so: undefined reference to `PrepareSystemFunction(asCScriptFunction*, asSSystemFunctionInterface*, asCScriptEngine*)'
libcodeblocks.so: undefined reference to `CallSystemFunction(int, asCContext*, void*)'
libcodeblocks.so: undefined reference to `DetectCallingConvention(bool, asUPtr const&, int, asSSystemFunctionInterface*)'
And more fun :)
I just couldn't try more because I gave little space to the linux partition and soon became full.
I'll have to burn some data, and then resize the ntfs and give more to the reiserfs one.
void* can be stored in a long or unsigned long without losing precision.
Edit: On 32bit and 64bit systems, long and ptr are the same size.
int is not long.
int on 64 bits platform is 32 bits if I remember well.
Quote from: mandrav on January 16, 2006, 12:25:14 PM
Here you go. Revision 1766.
Let us know of your progress :)
thanks i have a good application for using this !
Just a question, why does angelscript deal with void* typecasting? O.o What dark and obscure magic does it use?
Quote from: rickg22 on January 19, 2006, 01:18:18 AM
Just a question, why does angelscript deal with void* typecasting? O.o What dark and obscure magic does it use?
It's filled with void* all over the place. :D
I guess it's the most fastest way to bind functions. There are other ways more elegant and correct (like the ones in
boost::function and
boost::bind), but aren't as fast.
Quote from: Takeshi Miya on January 16, 2006, 01:27:02 PM
int is not long.
int on 64 bits platform is 32 bits if I remember well.
In most cases on 64 bit platforms long size = 64 bits = ptr size and on 32 bit platforms long size = 32 bits = ptr size. So you could change all those int's to long's. Or you could replace them with a typedef and have that controlled by a define like "PLATFORM_64_BIT". That way on 32 bit it stays like it is and 64 bit it is proper.
...and you could even insert
if(sizeof(long) != sizeof(void*))
cbThrow(_T("Doom is upon us, the evil seed of pointer hacks spreads. Run! Run!"));
at an early point to be 100% sure you know why your code crashes if it does.