Author Topic: command line build  (Read 8058 times)

nzoltan

  • Guest
command line build
« on: August 21, 2006, 04:33:52 pm »
If I try invoke C::B from command line without X, C::B doesn`t work:

$ codeblocks --help
Error: Unable to initialize gtk, is DISPLAY set properly?


So, I think a command line useful only, when work without X.

Offline walterwang

  • Single posting newcomer
  • *
  • Posts: 4
Re: command line build
« Reply #1 on: August 21, 2006, 05:02:54 pm »
C::B ist a IDE(GUI).
Why do you want a IDE to be run in command line?
If you prefer command line programming, you can use those combinations:
(under  windows)
shell: mingw or cygwin, so you can use pkg-config and other wonderful things.
and vim 7, which now support code completion(called omni-function) or emacs.
write Makefile manually or using Autotools.

nzoltan

  • Guest
Re: command line build
« Reply #2 on: August 21, 2006, 05:25:59 pm »
C::B ist a IDE(GUI).
Why do you want a IDE to be run in command line?

Because I want create an automatic build system. This run in every night, automatically checkout the project, rebuild and pack the binaries. Two options:

1. codeblock be able to build the project from command line and I invoke from build (shell) script

2. codeblock be able to export a makefile for this and I simply use "make" from my build (shell) script

3. ????
« Last Edit: August 21, 2006, 05:29:03 pm by nzoltan »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: command line build
« Reply #3 on: August 21, 2006, 09:34:15 pm »
Quote
1. codeblock be able to build the project from command line and I invoke from build (shell) script
As for now, this does not work, and it will not work. To make this work, you would have to build a minimum console-only version of Code::Blocks with an entirely different application body (free from
 wxWidgets). I am not sure if this can be done at all. Remember that the compiler binding is a plugin. Plugins communicate with the application via events. The compiler is launched via wxExecute... the list is endless.
Basically, you would have to rewrite 70% of Code::Blocks from scratch (unless there exists a wxWidgets port that works entirely without GUI and still offers an event loop - which I don't know).

Quote
2. codeblock be able to export a makefile for this and I simply use "make" from my build (shell) script
Makefile export is not supported any more. It may be again (some distant day in the future), maybe, possibly, but no grants on that.

Quote
3. ????
Yeah, that works fine :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

nzoltan

  • Guest
Re: command line build
« Reply #4 on: August 21, 2006, 09:59:31 pm »
Quote
Basically, you would have to rewrite 70% of Code::Blocks from scratch

Cool. Modular architecture... :)

Quote
Makefile export is not supported any more. It may be again (some distant day in the future), maybe, possibly, but no grants on that.

So, this is a very bad news. I not rely this. Consequently the solution is a hand written Makefile, and in C::B the custom Makefile settings.

Thanks your reply! This is an useful information.

Offline aurisc4

  • Multiple posting newcomer
  • *
  • Posts: 14
Re: command line build
« Reply #5 on: August 21, 2006, 10:07:21 pm »
Makefile export is not supported any more. It may be again (some distant day in the future), maybe, possibly, but no grants on that.

I really recomend to support this feature. It's very usefull. Command line compilation is much faster, than the one, using IDE. For big applications it'd be quite good to have makefile export feature, so you can develop app using C::B and do full rebuilds in command line.

takeshimiya

  • Guest
Re: command line build
« Reply #6 on: August 21, 2006, 10:48:11 pm »
Remember that the compiler binding is a plugin. Plugins communicate with the application via events. The compiler is launched via wxExecute... the list is endless.
Basically, you would have to rewrite 70% of Code::Blocks from scratch (unless there exists a wxWidgets port that works entirely without GUI and still offers an event loop - which I don't know).

You can get the  wxWidgets "port" that works entirely without a GUI by compiling with USE_GUI = 0.
wxExecute() works, and almost everything that is not ifdef'ed with wxUSE_GUI does.

The only problem is that wxBase haves no event loop yet (as of 2.6.x), but it haves an option for creating your own.
So the good thing is that there are several home-brewed (being used by other OpenSource projects) event loop implementation for wxWidgets base library.


I see that having a console only version of C::B will be very useful, specially for the build system (this becomes important to overcome the lack of the Makefile export feature).
BUT it will requiere a major effort in decoupling the GUI code from non-GUI code for the Compiler and Build system, so this should be postponed for the 2.0 (or 3.0) version.

One funny thing: the MS Visual Studio haves a decoupled non-GUI build system only in the very latest version of the IDE. Previous versions never had this feature.
« Last Edit: August 21, 2006, 10:49:50 pm by Takeshi Miya »

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: command line build
« Reply #7 on: August 21, 2006, 10:55:59 pm »
You should give try doing a speed test of Code::Blocks build system vs. Makefiles.  Code::Blocks is as fast or faster.

On topic:
Why can't you use a batch build for this? 

Having wxWidgets on your build server is not a problem and you should be able to open up and display windows even if there is no display attached (haven't tried this myself).

For the record wxWidgets starts up the message loop in wxApp::Initialize, so if you overload that method and do all processing there.  Then return with false and not call wxApp::Initialize you shouldn't have any problem.
« Last Edit: August 21, 2006, 11:06:33 pm by Game_Ender »

sethjackson

  • Guest
Re: command line build
« Reply #8 on: August 21, 2006, 11:02:46 pm »
You should give try doing a speed test of Code::Blocks build system vs. Makefiles.  Code::Blocks is as fast or faster.

On topic:
Why can't you use batch build for this?

On top of that building a project is easier with Code::Blocks than with a Makefile.....

nzoltan

  • Guest
Re: command line build
« Reply #9 on: August 21, 2006, 11:05:26 pm »
One funny thing: the MS Visual Studio haves a decoupled non-GUI build system only in the very latest version of the IDE. Previous versions never had this feature.

Delphi (!) had this feature from the begining... :)

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: command line build
« Reply #10 on: August 21, 2006, 11:48:30 pm »
Cool. Modular architecture... :)
Well, you would not expect Gimp to run without X either, would you... has nothing to do with being modular :)
I do see your point, it is indeed a nice feature to have, but it will be quite hard to implement as it is now.

You can get the  wxWidgets "port" that works entirely without a GUI by compiling with USE_GUI = 0.
wxExecute() works, and almost everything that is not ifdef'ed with wxUSE_GUI does.
Yeah well, Takeshi... that's exactly the problem. USE_GUI = 0 won't do us.
wxExecute() works
wxExecute in particular will not work, at least not the way we use it. For asynchronous operation, wxExecute posts data coming from the child process' pipe onto the message queue (and even more so, the compiler plugin uses the same mechanism to forward the events). It absolutely needs a functional message queue, or else the pipe will fill up and after 4k of output both the IDE and the child process deadlock.

Command line compilation is much faster, than the one, using IDE. For big applications it'd be quite good to have makefile export feature, so you can develop app using C::B and do full rebuilds in command line.
That's outright wrong. I have been building and testing "big" applications (well... 700-1300 source files, if you call that "big") both with makefiles and with Code::Blocks, and the Code::Blocks build system takes on the order of 30% less time.

For the record wxWidgets starts up the message loop in wxApp::Initialize, so if you overload that method and do all processing there.  Then return with false and not call wxApp::Initialize you shouldn't have any problem.
I have no experience with this, so there's little I can tell, but I would be surprised if it were that easy (though it would be good). You still have to emulate a genuine event loop IMO, or else none of your pipes will work (they all rely on the event loop). For our own stuff, we could call the plugin member functions directly instead of sending messages, but that won't hold true for the pipes. Of course, one could simply use popen() for that special case, too... but then we're no longer cross-platform, and I am not sure inhowfar it is painless to integrate something like popen() into the build process (which runs asynchronously, controlled by events).
« Last Edit: August 21, 2006, 11:50:16 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."