Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Build Update

On 3 Mar 2010, at 00:29, Doug Schaefer wrote:

> I started taking a fresh look at build first after the experience I had integrating a previous employer's toolchain. I just found it was too much work to do the customizations that I needed to do, for example setting a common argument for both the compiler and linker. It was pretty painful. And I never did get scanner discovery to work consistently. And from the complaints in the past I wasn't alone.

I found it was a lot of work to add -framework as a recognisable argument for the Apple GCC compiler too. :-) Part of it was lack of documentation, and part of it was the code base (you can call setOption, but it doesn't persist until you do project.setDescription?).

> In the end, this is a much easier piece for me to bite off, and I think it adds the most value to the community. Our existing managed build seems to be working well enough, and I think it has it's place, especially for Visual Studio users migrating over to IDEs like Wascana. But I want to make it easier for Linux and embedded developers to who have different workflows that they're used to. And, of course, I want to make sure CDT is the best open source IDE against our rivals in Qt Creator, KDevelop, etc. :)
> 
> I'd love to hear what you think. Please let me know,

I think there's a lot of Unix tools which use autoconf to generate a makefile, so it would be good if CDT could if not parse autoconf, then at least allow it to make a project with AutoConf by running ./configure (and supplying options, where necessary) followed by making it. 

Lastly, for Apple bundles, the executable has to be in a particular directory structure (e.g. Foo.app/Contents/MacOSX/foo). There may be ways of attaching things to do after the build, but being able to reorganise where the compiled output sits, other than the top-level directory, would be good for that point of view. I suspect the same may apply for tool suites (like bind/dhcp) where there may be many executables produced at different levels of the (source) tree, which may be compiled into a single top-level location.

Alex

Back to the top