Skip to main content

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

Thanks, guys. This is great feedback. Comments below.

On Tue, Mar 2, 2010 at 8:43 PM, Michael Jackson <mike.jackson@xxxxxxxxxxxxxx> wrote:

On Mar 2, 2010, at 8:30 PM, Alex Blewitt wrote:

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.

The Linux tools project does have a autotools plug-in. That's what I was referring to with the work Jeff from Red Hat has been doing. And it does pretty much what you're saying.
Lastly, for Apple bundles, the executable has to be in a particular directory structure (e.g. 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.

cdt-dev mailing list

 From a CMake perspective I would like to see a little "better" support for CMake although I am not really sure what that entails. Here is snap shot of the "landscape" as seen through a CMake users eyes.
  CMake will itself generate Eclipse CDT project files but there seems to be some ugly hacks to allow for the separate build and source directories because CMake will generate the project files inside the _build_ directory, NOT inside the project directory which are 99.9% of the time different directories. Some folks (like myself) place the build directory as a directory inside the project folder. Obviously, CMake will also generate Makefiles on Linux and OS X in addition to MinGW makefiles, MSYS makefiles, CYgwin Makefiles and Unix Makefiles on Windows. I think what would be nice would be for Eclipse to have as part of its "New Project Wizard" an "Existing CMake Build Directory Importer" where CDT would basically parse the CMakeCache.txt file to gather the needed information (like where the source directory is, what include directories are needed and stuff like that) and also add some push buttons to rerun CMake as needed to the UI (maybe as an External Tool). Other than that, a CMake project is just a "Makefile" project which works out fine for me. I helped update the "CMakeEditor" Eclipse plugin which adds the needed syntax highlighting and command completion for CMake files.
  If someone is starting clean and wants a CMake project the wizard could ask for the Source and Build directories and setup some basic things needed for the project, then execute CMake on the source directory. QtCreator does something like this and seems to work OK.

That's a thing I've been wondering about too. Right now we have new C and C++ project wizards. I'm wondering if that's too general and leads to usability issues. I notice a number of commercial offerings have their own New Project wizards and don't extend the CDT's. Is that just because they are older? I'd love to hear why things are like that so we can serve the community better.

So, for the qmake/Qt integration, I was thinking of just doing a new Qt project wizard, just like the Qt Eclipse integration does. That way I can customize the wizard to provide the information to populate the qmake pro file. I imagine the same thing for CMake.

BTW, I find CMake's CDT project generator weird. We've always claimed the .cproject format and contents to be internal interfaces which could change at any time. And you have a chicken/egg situation. If you are using the CDT with your project, you'll already have these files created. At any rate, I'd prefer to use CMake as a Makefile generator only.

I'm going to tackle qmake first and use the lessons learned to add in CMake, time permitting, of course, and the chances grow if someone helps ;)

Back to the top