Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Summit Agenda - Build System questions

On Tue, Sep 9, 2008 at 11:33 AM, Elmenthaler, Jens <jens.elmenthaler@xxxxxxxxxx> wrote:

Hi Doug/Chris,

 Sorry for spoiling the original scope of this thread, and yes - I agree to both of you.

This is so adorable. I agree with all three of you. Generated makefile there needs to be and I so like Doug's idea of generating makefile on request.

Of course. Most CDT users actually use standard make, especially in the commercial world. We'd be fired if we got rid of it ;).
Again, I could not agree more. I just can't figure out why Standard Make gets so little attention from the committers. Or, let me rephrase, why there are so few (0?) committers devoted to improvements in that area.    

One driver is the need to find the errors early. Since Monday I understand that symbolic links for include paths or header files are a bad idea. After applying a workaround to my plugins, turning on syntax coloring for the indexer problems comes close. This is really  a big achievement! Give Markus another year and the ability to tame templates and the standard headers – done.


The second driver for me is large projects and users who know which directories to build in order to go debugging right away. I guess make targets are supposed to do that. However, in large projects running a make target refreshes the entire project which nullifies all the time advantage (, this is actually blocking me from doing it myself).

Yes, this is a major one. 


Then a make target could be created dynamically according to some user setting specifying the target. It uses the same builder as the project and the working directory is the one of the saved resource. All that is remaining to a user in this scenario is to manually run the make target for the executable, shared library, etc (which is nothing at all in most of our cases).

Make targets in Make Targets View can also be a fine engine to allow building of different types of build output in the same project. One make target builds executable, another makes shared library, yet another static code analysis tool. Generating these targets automatically works very well as we do in our projects. It would be very valuable to have that ability in CDT.    


Greetings, Jens.



Back to the top