Jump to: navigation, search

Linux Tools Project/Autotools/Rewrite Changes Guide


The Autotools plug-in for Linux Tools 0.4 has been rewritten. The main reason for the rewrite is that the old plug-in was accessing internal CDT APIs which meant that it would break easily whenever the CDT was updated. In addition, the project was originally based on a CDT Managed Make project which was not appropriate. A Managed Make project is meant to automatically generate a Makefile from input files and known tools and tool settings. This doesn't really apply to an Autotools project where the Makefile is generated by the configure step and doesn't set up tools ahead of time. Using the Managed Make project as a base exposed functionality that did not apply to an Autotools project. For example, at one point the gcc and g++ compiler tool settings were exposed to the end-user but these settings were never used.

The rewrite has changed the Autotools plug-in (now version 2.x) to base an Autotools project on a CDT Makefile project which makes more sense in view that a Makefile is actually used to perform the build and is not under control of the CDT Managed Make facility. This change in base project requires some modifications to the Autotools plug-in UI.

Old projects (1.x) will continue to work the same for a time due to the addition of a compatibility plug-in. This compatibility plug-in will eventually be phased out as it will become more and more difficult to maintain it with updated CDT releases. For example, there is currently a bug introduced by CDT 6.0.1 whereby a Null Pointer Exception occurs in the Discovery Tab of the C/C++ Build page (https://bugs.eclipse.org/bugs/show_bug.cgi?id=291690). There is no workaround at the present time for projects created prior to the Autotools workaround fix. Users should not click on this page as it has no useful function for an Autotools project.

All new projects created will be version 2 as will any projects that are converted. Converting an old Autotools project to a new one will result in loss of configuration data (i.e. you will have one default configuration after conversion). Note that there is no way to convert back to an old format project except by removing project information and using an old 1.x Autotools release to (re-)create the project.

The following section describes changes between old and new Autotool projects.


One major noticeable change is that the Tool Settings tab found in Project -> Properties -> C/C++ Build -> Settings no longer exists. This used to contain the settings for the configure and autogen.sh scripts. The absence of the tab is in line with a CDT Makefile project which does not expose tool settings. Since the Autotools plug-in still requires parameter setting for the configure and autogen.sh script, a Configure Settings page has been added to Project -> Properties -> Autotools. The UI is nearly identical to that shown in the older 1.0.x version of the Autotools plug-in, except there is no longer a build directory parameter.

The build directory is now in full control of the CDT under the Project -> Properties -> C/++ Build page, specified as the build location. By default, a new Autotools project will build in the top-level project directory unless this is altered. This is in line with many open source autotool'd projects which suggest configuring and building in the source directory. Subsequent configurations added will automatically create build directories in the project called: build-xxxxx where xxxxx is the configuration name with white-space characters replaced by underscores. This behaviour can be turned off from the Project -> Properties -> Autotools page. The old methodology was to default the initial build to have a "build" directory and whenever a configuration was created or copied, a check was done to see if two configurations had the same build location. When this occurred, a numeric qualifier was added/changed for the directory (e.g. build2, build3, ...).

There is no longer a pre-build or post-build step. This is a Managed Make construct that doesn't apply to CDT Makefile projects. For projects that depend on this behaviour, one can manually add builders to perform the task required and position them to occur before or after the system builders. See Project -> Properties -> Builders.

The Autotools tab formerly found in the Project -> Properties -> C/++ Build -> Settings page is removed. Autotools settings are now via the Autotools page which is a cleaner design.

The Autotools plugin now properly uses Scanner Discovery and has removed its internal file scanner. The old file scanner would perform a make -W for each file which was difficult to scale for large projects. Using the new discovery profiles enables data to be scraped from a single build.

Internally, the Autotools builder has changed to just perform the configure step and nothing more. This makes the design much cleaner and prevents the Autotools plug-in from interfering with CDT build changes. For example, Make Targets are actually built by the CDT Builder now instead of the Autotools builder. Parameters for configure and autogen.sh are no longer stored in the .cproject file. Instead, a new file, .autotools, is created in the project. This was necessary because the tool settings are no longer automatically stored inside the internal CDT configuration. Saving these externally avoids any requirement to access the internal CDT Configuration class.

For details on the new Autotools plug-in, see the User Guide.