Skip to main content

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


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.

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_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


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.

Cheers
_________________________________________________________
Mike Jackson                  mike.jackson@xxxxxxxxxxxxxx



Back to the top