Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Query on the Philosophy of the Build System

<< < (3/3)

Stevo:

--- Quote from: Game_Ender on January 25, 2006, 01:55:19 am ---You have spent at lot of time writing but a little bit more time look would shown you that anything build system options can be set on and IDE, Project, or target basis.  This include compiler.  So you could have your project compile under 5 different compilers and then a 6th custom one to link it all together.  Just go to build options, click you target and change "Selected Compiler".

--- End quote ---
I dont see it. 

If i right click on the file, the only possible option that could be relevent is properties, if i select that, the only option that seems to do what you say is build, which lets me specify custom builds commands, granted, but i would have to do that individually for each file, which hardly seems efficient.

Or are you saying to have different targets, one for each compiler?  or sub result?  I have now found where i would do the link map/.elf auto dependency, so the process if i had that occur in other places would be for each of those to be their own target?

And for the "Project" to bind the result together?

But i still dont see how i would specify different compilers, the only place i can see to set the compiler executable names is under:
settings/environment/global compiler settings

And yes, i can copy GCC and specify different GCC's for embedded targets, etc.  I dont see anyway to select those at a target level, because the "Selected Compiler" option in "Project Compiler Options" is greyed out?

i cant find any way to over-ride this on a file basis, or a target basis.

Im using C::B Cvs from about 2 days ago.


--- Quote from: Game_Ender on January 25, 2006, 01:55:19 am ---About the tool chain issue.  I think it would be a good idea to look into a way to make a stand alone codeblocks build system.  I think there would be some difficulty in a completely standalone system because for better or worse the entire project uses, including the debugger plugin uses wxstrings, wxchars, and the wxwidgets event system.  With that said, you could probably make a build system that had no GUI but still needed wxwidgets around but didn't have a GUI a little easier.

--- End quote ---

Granted, this would address a number of philosophical points i raise in my post, but if this was done, what would be gained by having it "integrated" into C::B at all then?  It could still be part of the C::B project but if it could be built to run stand alone, wouldnt it make sense then for C::B to just execute it as a utility, and capture its output (just like it does for a custom makefile?)  Basically the only difference would be the build script files would be graphically maintainable by C::B.


--- Quote from: Urxae on January 25, 2006, 02:26:15 am ---C::B can be used from the command line. I do so every day. (Actually, I use a shortcut. But that's just for convenience)

--- End quote ---

This is the first ive heard that, can the defaults be supplied so it never asks?  I just tried it, and it works as expected, but it stops at the end of the build, and i had to press ^C to terminate?


--- Quote from: Urxae on January 25, 2006, 02:26:15 am ---Okay, so C::B isn't contained in one file, and still needs wxWidgets to be present even if the GUI isn't used. I'll give you that one. However, no installer is necessary (It'll request vital information like where the compiler is on first run) and it can be put anywhere.
Running it is easy, and can be made even easier by a one-line script that provides the right parameters.

--- End quote ---
This assumes the correct version of wxWidgets is installed, no?


--- Quote from: Urxae on January 25, 2006, 02:26:15 am ---If you need to provide the complete build environment, I presume that includes the compiler (esp. if you want a bitwise-equal result). My compiler is about 27 MB compressed (MinGW, zipped). C::B + wxWidgets is about 6 MB zipped. Doesn't seem like a huge overhead in comparison (though admittedly probably more than make or jam will take up).

--- End quote ---

Part of my automated build for a regulator is an automated installation of all of the tools, and yes i can also auto install code::blocks.  A Primary issue with this process is removed being able to build using C::B from the command line, but i still dont think end users should always be subjected to a gui, just to build the code (again its a philosophy thing)  And yes, i agree with the previous post about "You use yours and ill use mine", thats not the point of this, its just to see where its going, and what it aims to achieve, and how is it planning on being better than the current tools available?


--- Quote from: Urxae on January 25, 2006, 02:26:15 am ---What's the fundamental difference between two compilers with compatible output or two frontends for the same compiler?
I'd bet that if I put together a project that created a library and an executable, with different but compatible-output compilers it'd link together just fine. After all, that's the definition of "compatible output", is it not?
Unfortunately though, I only have one compiler installed so I'm not in a position to try.
Oh, and this does not allow directly linking object files generated by different compilers together. So what? That's what static libraries are for (amongst other things).

--- End quote ---

The difference between 2 front ends, and 2 compilers is, with 2 front ends, you select the compiler with a compiler option, 2 compilers use 2 different executables.  As ive said, i can find no way (that works for me) to alternate the compiler executable on a file or target basis.

See above, i cant see how it can, cause the options are greyed out...

Also,

The other thing a modern build system should be capable of (which i havent touched on before) is parallel builds (compiling multiple independent files simultaneously) so that multi-processor machines can accelerate long build processes.

Stevo

thomas:

--- Quote from: Stevo on January 25, 2006, 04:01:18 am ---
--- Quote from: Urxae on January 25, 2006, 02:26:15 am ---C::B can be used from the command line. I do so every day.
--- End quote ---
This is the first ive heard that, can the defaults be supplied so it never asks?  I just tried it, and it works as expected, but it stops at the end of the build, and i had to press ^C to terminate?
--- End quote ---
It may be that you experience one of the dreaded Linux hangs there, that's a yet unresolved bug though, not a feature. Generally, it terminates after building. I only use Code::Blocks on Windows, and luckily it does not hang there.


--- Quote from: Stevo on January 25, 2006, 04:01:18 am ---
--- Quote from: Urxae on January 25, 2006, 02:26:15 am ---Okay, so C::B isn't contained in one file...
--- End quote ---
This assumes the correct version of wxWidgets is installed, no?
--- End quote ---
Just unpack the archive.


--- Quote ---Some of my custom data takes minutes to generate (on a very fast computer) and i dont want to do it if i dont need to.
--- End quote ---
Well yes, that's what is usually the case if you process data. Luckily, that's what bash has test -nt for, works like a charm, even on Windows :)
OK, maybe it would be better if the IDE already had built-in functionality for this, somehow. But then, where do you start and where do you stop. An IDE is no divination apparatus, after all, and it cannot foresee every possible thing that someone might want to do. That's what we have scripting for :)

sean345:
The lcc-win32 IDE has a nice build system.  I'm not sure if this is possible with C:B (I haven't seriously tried), but if I add a file to the project that the IDE does not know what to do with (i.e. not a *.c or *.h file in the case of lcc-win32), the system asks me how to build it.  I can specify to use the compiler or I can choose another program to "compile" or interact with the file.  I am also given the option to automatically add a generated file to the make file as a dependency of the original (i.e. test.md is read by a program called lburg and test.c is generated as output and then compiled in with the project). 

I would like to be able to do this in C:B.  If this is already possible, could someone point me in the right direction?

Thanks,
 - Sean

Navigation

[0] Message Index

[*] Previous page

Go to full version