Community
Participate
Working Groups
A lot of C/C++ development is done using GNU autoconf and automake systems, usually in tandem. It would be nice to have convenient integration of these systems with Eclipse, especially as they provide lots of the "extra information" that basic Makefile(s) lack to provide traditional "IDE information"...specifically things like detecting executable build targets or built libraries. The basic flow of use is as follows: - user checks out a module from CVS, contains Makefile.am, configure.in (or configure.ac) and often autogen.sh (only a convention, but followed by many projects) - Running autogen.sh will usually run a series of commands to setup macros properly and generate a "configure script". Usually the commands are something like: libtoolize, aclocal, automake --add-missing, autoconf. But its important to recognize that many modules have their own special commands that need to be executed here (for example, intltoolize, an i18n tool, may need to be run). Thus it is best to run autogen.sh if it is present. - At the end of autogen.sh a "configure" file will be generated in the local directory. Unless the user alters configure.in, this probably won't need to be generated again. Configure usually accepts a series of options, some standard (such as --prefix=/dir which alters where it builds to... it would be nice if Eclipse automatically built things into the workspace somehow) and some defined by the configure.in file. - After running configure, a diving Makefile system will be generated from the various Makefile.am's. auto* systems have a few standard special targets besides the default, including "make dist", which makes a shippable tarball, and "make distcheck" which runs certain pre-release checks. One nice thing about auto* is that the Makefile.am files are in such a format that they can be semi-reasonably parsed and interpreted. Anjuta2 (http://www.gnome.org/projects/devtools/gide.shtml), for example, already has this capability and can read in any auto* project and produce a convenient list of binary and library build targets, special commands for building tarballs, etc.
Very interesting. But how do you deal with the configure, Obviously you may want to pass options to change the behaviour enabling disabling some features. How to handle the UI side. Are you interested in working on this ?
PR was not targeted to any particular release. Changing target milestone to 2.1
All of my C/C++ projects use GNU auto build tools. Eclipse would be much more useful for me if it integrated cleanly with existing autoconf/automake based systems. (KDevelop is a fine IDE that honors the GNU auto-tool formats) As for dealing with configure, KDevelop (http://www.kdevelop.org) may be a useful guide for designing a usable user interface.
*** Bug 78560 has been marked as a duplicate of this bug. ***
A few notes on this topic... For "configure" UI, the simplest is to just let the user edit the options. You could try to parse the output of "configure --help", but usually this doesn't provide enough information to build a better UI. (You could lobby the autoconf maintainers, but ...) Using autogen.sh is nice. Some projects call this "bootstrap". Projects that don't have these files will often use "autoreconf". Some projects check in their generated files. Usually a project is tied to a particular version of these tools, it is important not to just run "automake" but instead let the user pick the name so he can force "automake-1.9" or whatever. It would be nice to pick sensible defaults for --prefix so that a simple build would install somewhere in the workspace. Sometimes people like to build in a separate directory as well; at least one project (GCC) doesn't always support building in srcdir. Automake provides a number of standard targets. The ones that make sense for Eclipse, I think, are: all, install, uninstall (not used much though), install-strip (likewise), clean, distclean, mostlyclean, maintainer-clean (more dangerous), info, dvi, dist, check, installcheck (not used much), distcheck. (There is also installdirs, which afaik nobody uses, and TAGS, which isn't useful in Eclipse) Eclipse by default could configure with --enable-maintainer-mode so that changes to the auto* input files are automatically handled during a make. More advanced ideas. It wouldn't be too hard to parse Makefile.am and notice that, say, a given directory only has one installable (a library or program). Then a new source file in that directory could automatically be added to the appropriate _SOURCES variable there. (In more complex cases you might have to ask the user somehow.) It would be possible to make a "portability dictionary" (a la autoscan) that integrates with eclipse, so that non-portable code is flagged and the user is given the option ("Quick Fix" perhaps) of adding an appropriate check to configure.ac.
Is there any way that I can help with this?
*** Bug 81907 has been marked as a duplicate of this bug. ***
The KDE-Eclipse project has some integration with the autotools. http://kde-eclipse.pwsp.net/index.php It's apparently EPL licensed, too.
Copying Jeff who is working on such a solution.
The plugin is located here for those who are interested and want to help out or try it: http://sourceware.org/eclipse/autotools/
None of the committers are currently working on this. Contributions welcome.
*** Bug 117994 has been marked as a duplicate of this bug. ***
Just to let people know that the latest Red Hat Autotools plugin source has been updated in the CVS repository and is finally running reasonably with the new and improved CDT 4.0 project model. Make targets are now supported through the Project Make Target menu interface. The Autotools plugin automatically preloads the top-level Makefile targets for you once the configure is performed. As before, autogen.sh is automatically supported. Configure options are supported in the Project Properties -> C/C++ Build -> Settings dialog. Multiple configurations are supported. Configure is treated as a tool with settings and the configure tool settings are stored per CDT configuration (i.e. you can set up multiple builds with different configuration settings). I have been working extensively to clean the Autotools plugin project so it has no internal CDT class references or patches required. This will go a long way to making it stable and being able to contribute it at a later date directly to the CDT.
Future means you commit to fix it in the Future. Inboxes can't make committments. Moving to '--'.
Should this be covered by the Linux Tools project by now? That scope does not sound exactly right -- GNU autotools are not only for Linux, but there is indeed an autotools plugin in incubation.
(In reply to comment #15) > Should this be covered by the Linux Tools project by now? > That scope does not sound exactly right -- GNU autotools are not only for > Linux, but there is indeed an autotools plugin in incubation. I would say yes but the Linux Tools project isn't targetting Windows ATM.
(In reply to comment #16) > (In reply to comment #15) > > Should this be covered by the Linux Tools project by now? > > That scope does not sound exactly right -- GNU autotools are not only for > > Linux, but there is indeed an autotools plugin in incubation. > > I would say yes but the Linux Tools project isn't targetting Windows ATM. True, there are a collection of tools that also work on Windows there and at some point we should figure what we want to do with them. I am starting out to rethink the CDT build system. One objective would be to make autotools based projects more natural (another would be to better support pkg-config). Maybe once that's in place we can bring the autotools support over to the CDT since it is more than just Linux. BTW, other than Windows, does Mac have support for autotools? I'm not sure how *nix'y it is.
(In reply to comment #17) > BTW, other than Windows, does Mac have support for autotools? I'm not sure how > *nix'y it is. Yes, AFAIK they work just fine there.
So this is actually being done in the Linux tools project. I'm wondering why this is still open. Wondering so much I'm going to mark it fixed.
(In reply to comment #19) > So this is actually being done in the Linux tools project. I'm wondering why > this is still open. Wondering so much I'm going to mark it fixed. Because this could be used on Windows and Mac. At least, I would use this.
(In reply to comment #20) > (In reply to comment #19) > > So this is actually being done in the Linux tools project. I'm wondering why > > this is still open. Wondering so much I'm going to mark it fixed. > > Because this could be used on Windows and Mac. At least, I would use this. Of course, but the plug-ins Jeff has put together should work there too.
(In reply to comment #21) > (In reply to comment #20) > > (In reply to comment #19) > > > So this is actually being done in the Linux tools project. I'm wondering why > > > this is still open. Wondering so much I'm going to mark it fixed. > > > > Because this could be used on Windows and Mac. At least, I would use this. > > Of course, but the plug-ins Jeff has put together should work there too. Thanks Doug, I tried it on Mac and it works. I think it's confusing to the user that this feature lives in the Linux Tools project since it's more related to C/C++ and not specific to Linux. Maybe the feature should be moved to CDT? Is that even possible? If so, how should the discussions begin? On the linuxtools-dev mailing list?
In my rewrite of the CDT build system, I am considering how autotools would plug into it more naturally. When I get enough going on this I'll work with the Linux tools guys to transition that over to the CDT as a first class citizen. That is already mentioned in my defect on the new build system.
