Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Linux Tools Project/Autotools/Rewrite Changes Guide"

(Changes)
(Introduction)
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Overview =
+
= Introduction =
  
The Autotools plug-in for Linux Tools 0.4 has been rewritten.  The reasons for the rewrite was that the plug-in was accessing internal CDT APIs which meant that it would break easily whenever the CDT updated.  In addition, the project was originally based on a CDT Managed Make project and was exposing functionality that did not apply to an Autotools project.  For example, at one point the gcc and g++ compiler tool settings were exposed which are meaningless for a project that has a Makefile.
+
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.
+
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 will continue to work 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 keep it working with CDT releases.  All new projects created will be the new format as will projects that are converted.
+
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.
  
The following describes changes between old and new Autotool projects.
+
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.
  
= Changes =
+
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.
+
= Changes =
  
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 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 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, ...).
+
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.  
  
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 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, ...).  
  
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.
+
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 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.
+
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.  
  
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 Makefile 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.  This avoids any requirement to access this structure internally.
+
The Autotools plugin now properly uses Scanner Discovery and has removed its internal file scanner. The old file scanner would perform a <tt>make -W</tt> 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.  
  
For details on the new Autotools plug-in, see the [http://wiki.eclipse.org/Linux_Tools_Project/Autotools/User_Guide Autotools User Guide].
+
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 <tt>configure</tt> and <tt>autogen.sh</tt> are no longer stored in the <tt>.cproject</tt> file. Instead, a new file, <tt>.autotools</tt>, 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 [[Linux_Tools_Project/Autotools/User_Guide|User Guide]].

Latest revision as of 14:57, 2 December 2009

Introduction

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.

Changes

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.

Back to the top