Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Contributions to C::B => Topic started by: ivucica on September 10, 2007, 12:21:42 pm
-
Hi,
since MinGW runs under GNU/Linux, it might be interesting if someone added detection of MinGW compiler, and that in such case targets with Windows platform specified are also processed. Perhaps some kind of Devpak installer for Linux, as a side project, might be interesting.
-
Adding a MinGW Crosscompiler is a absolutly simple task, so I don't think it is necessary to have this built in. There should be an wiki entry for this.
-
Adding a MinGW Crosscompiler is a absolutly simple task, so I don't think it is necessary to have this built in. There should be an wiki entry for this.
I think there's one already
-
Adding a MinGW Crosscompiler is a absolutly simple task, so I don't think it is necessary to have this built in. There should be an wiki entry for this.
Already there: Code::Blocks and Cross-Compilers (http://wiki.codeblocks.org/index.php?title=Code::Blocks_and_Cross_Compilers).
-
It should, however, automatically detect MinGW. I ask nothing more ;)
There probably is many users out there who would use this, but are not aware of the possibility to do so.
-
It should, however, automatically detect MinGW. I ask nothing more ;)
How would you do that? Most users extract the compiler that is mostly shipped as tar.gz to any place on their HDD. Should C::B really search across all your (320GB) HDD's to find MinGW if you know where it is? Any maybe you have two version of GCC installed (as I do) - should C::B just guess which one to use? No thanks. We look at the default "installation" path which is C:\MinGW. If it's not there - the user has to configure it. Period.
With regards, Morten.
-
It should, however, automatically detect MinGW. I ask nothing more ;)
How would you do that? Most users extract the compiler that is mostly shipped as tar.gz to any place on their HDD. Should C::B really search across all your (320GB) HDD's to find MinGW if you know where it is? Any maybe you have two version of GCC installed (as I do) - should C::B just guess which one to use? No thanks. We look at the default "installation" path which is C:\MinGW. If it's not there - the user has to configure it. Period.
With regards, Morten.
I totally agree with you, that the user has to configure it, if a quick search dosn't find MinGW cause searching the entire HDD is not an option but taking a look at the path enviroment variable (like whereis on linux) could be an option (also for Windows).
denk_mal
-
but taking a look at the path enviroment variable (like whereis on linux) could be an option (also for Windows).
This still does not solve the issue if you have more than one gcc compiler installed and (possible, too) you have another tool called gcc.exe for example. I promise: We would get the same amount of user requests saying MinGW was not detected or false detected due to that as we have now.
With regards, Morten.
-
I totally agree with you, that the user has to configure it, if a quick search dosn't find MinGW cause searching the entire HDD is not an option but taking a look at the path enviroment variable (like whereis on linux) could be an option (also for Windows).
Definitely it's an option. But MinGW cross-compiler is not widely available in all distros. Also the available version is quite old and comes with GCC only.
I prefer to not to use /usr/local dir to compile and install the cross-tools. In two of my PCs they are in /usr/local/cross-tools dir and in /home/biplab/cross-tools dir. This is one such possible cases where C::B will fail to detect it even with a whereis patch (unless one adds it to PATH).
Trust me, only couple of clicks are necessary to get it working with C::B. I believe that is not too difficult. :)
-
Definitely it's an option. But MinGW cross-compiler is not widely available in all distros. Also the available version is quite old and comes with GCC only.
Which distros do you mean by this? Ubuntu 7.04 had IMO the latest release of MinGW and my Lenny offers the 4.2-sjlj TechPreview. Both with g++
-
Definitely it's an option. But MinGW cross-compiler is not widely available in all distros. Also the available version is quite old and comes with GCC only.
Which distros do you mean by this? Ubuntu 7.04 had IMO the latest release of MinGW and my Lenny offers the 4.2-sjlj TechPreview. Both with g++
Sorry for this late reply. I didn't notice your post.
I use Fedora 7. I found a very old version. Then I compiled GCC-4.2.2 to do the cross-compiling. :)
-
How would you do that? Most users extract the compiler that is mostly shipped as tar.gz to any place on their HDD. Should C::B really search across all your (320GB) HDD's to find MinGW if you know where it is? Any maybe you have two version of GCC installed (as I do) - should C::B just guess which one to use? No thanks. We look at the default "installation" path which is C:\MinGW. If it's not there - the user has to configure it. Period.
With regards, Morten.
I'm talking about cross compiling (look at topic title) ;)
Like most crosscompilers I found, MinGW under Debian is installed under /usr/, more specifically, into /usr/i586-mingw32msvc. There we can find usual bin/, include/, lib/ folders. Nobody said anything about searching entire hard drive. Your statement about only C:\MinGW being supported is also incorrect -- I've seen many machines where MinGW was installed into C:\Dev-Cpp, and C::B properly detected it.
Something tells me that the MinGW compiler will be installed in:
1. /usr/*mingw*
2. /usr/local/*mingw*
3. /opt/*mingw*
Searching inside those folders for ./bin/gcc, perhaps also querying for gcc --version, should provide enough information to "claim" that MinGW cross-compiler is installed into that folder, by virtues of autodetection.
Topic #2
On the other hand, there's another thing that C::B may be lacking in. I am considering using it for PalmOS development, since I don't want to get Palm-customized version of bloat called Eclipse installed. It made me happy when I saw I can choose a custom Makefile. However, launching the program is a bit trickier thing.
There is a freely available PalmOS emulator "pose", and by agreeing to some additional License Agreements ;) it is possible to get ROMs for that emulator. PRC Tools generate a .prc file (the "executable" on Palm devices). I'd like to automatically transfer it to Palm emulator, by running some commands (more specifically initiate a transfer to the Palm) upon building.
Similar things are done for PocketPC, including running. Both things need custom commands that would be executed upon running. Only ways to remedy this for me are currently are adding a custom tool. That would make testing program a two step process: building (ctrl+f9) and running (alt+t, and then choosing tool).
Running with Wine only works because the Linux kernel can detect PE format and run Wine instead of directly running the application. Requiring such thing with .PRCs and PE/ARM is not very efficient, and probably not possible, since the application is not really executed on the machine (POSE requires a third step of launching the application inside the emulator, WINCE does not even have an emulator for GNU/Linux).
This could be remedied by simply adding another line in this dialog: Settings->Compiler and debugger->Global compiler settings->Toolchain executables. Adding line such as "Launcher" would do much to help me and others who consider C::B for embedded development. Then, when starting the executable, simply prepending the command line with the contents of the option would suffice.
Other possibility is adding a similar thing into Project->Properties->Build targets. Since the selection of "Selected build type options->Type" between GUI application and Console application already modifies the command line (the cb_console_runner), this might also be a logical place to put it, although it's more of platform ("toolchain") specific than project specific thing.
And before anyone suggests so, yes, it would be possible for me to modify the custom makefile, but let's pretend that I want to use C::B's UI for project file management wherever possible.