Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Backticks in Windows Shell/Code::Blocks?

(1/5) > >>

takeshimiya:
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?

thomas:
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).

mandrav:
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).

takeshimiya:
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.

--- End quote ---

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
--- End quote ---

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).

thomas:

--- Quote from: Takeshi Miya on January 16, 2006, 09:16:06 am ---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.
--- End quote ---
Luckily, we have somebody working on autotools import now, so that will solve that issue. :)

Navigation

[0] Message Index

[#] Next page