Community
Participate
Working Groups
Build Identifier: M20110210-1200 As it stands, if any options are needed by default, for example, for a particular toolchain, they must be added by the user, using the project settings dialog, after an autotools project is created. This is inconvenient and error prone. As an example of this, as the creators of the IBM Advance Toolchain, we'd like for the following options to be added to the configure command by default: CC=<path_to_our_gcc_compiler> CXX=<path_to_our_g++_compiler> If these switches are not added, the generated Makefile will contain references to gcc and g++ and if the user doesn't have our tools ahead of /usr/bin on his $PATH, he will get the wrong tools. To solve this problem, an extension point could be provided that allows other plug-ins to add arbitrary switches to the configure invocation. Reproducible: Always Steps to Reproduce: N/A
Created attachment 196501 [details] Patch that adds extension point which allows configure options to be supplied by other plug-ins This patch is an example of how Autotools could make it fairly simple to add new options to the configure command, by adding an extension point. It's not designed to handle more than one toolchain adding switches to configure, however. A more elaborate solution allowing a user to select different toolchains, each with different configure options would be needed, if that capability is desired.
Created attachment 196502 [details] Example of using the extension point provided by the patch. This is a simple example of using the extension point to add two options to the "configure" invocation.
Thanks for the patch, Corey. I'll let Jeff comment on its contents but I wanted to let you know that we've already submitted our IP log for Indigo (our 0.8 release) so this can't be in that release. It can definitely be considered for our Indigo SR1 contribution.
Created attachment 196503 [details] Example of using the extension point provided by the patch. Example of using the extension point provided by the patch. (this version gets rid of an irrelevant extension to another plug-in)
(In reply to comment #3) > Thanks for the patch, Corey. I'll let Jeff comment on its contents but I > wanted to let you know that we've already submitted our IP log for Indigo (our > 0.8 release) so this can't be in that release. It can definitely be considered > for our Indigo SR1 contribution. Sure, that's fine. Thanks!
Any comments on this patch, Jeff? The patch has been working OK for us, but we are now starting to see that it may be insufficient, that we may want actual toolchains similar to what's available in the CDT. For example, in project A, I want to use the distro-provided gcc/g++ compilers, but in project B, I want to use our special compiler. That would seem to imply that we need to have some sort of toolchain selection ability. Also, it would be nice if the compiler switches could mimic what's provided by a conventional CDT toolchain. For example, being able to specify different optimization levels, which is typically done on the command line via: ./configure CFLAGS="-g3 -O0" CPPFLAGS="-g3 -O0" ... Since CFLAGS and CPPFLAGS are not necessarily processed by all configure commands, it might be misleading to provide this capability, though. Any thoughts?
(In reply to comment #6) > Any comments on this patch, Jeff? > > The patch has been working OK for us, but we are now starting to see that it > may be insufficient, that we may want actual toolchains similar to what's > available in the CDT. > > For example, in project A, I want to use the distro-provided gcc/g++ compilers, > but in project B, I want to use our special compiler. > > That would seem to imply that we need to have some sort of toolchain selection > ability. > > Also, it would be nice if the compiler switches could mimic what's provided by > a conventional CDT toolchain. For example, being able to specify different > optimization levels, which is typically done on the command line via: > > ./configure CFLAGS="-g3 -O0" CPPFLAGS="-g3 -O0" ... > > Since CFLAGS and CPPFLAGS are not necessarily processed by all configure > commands, it might be misleading to provide this capability, though. > > Any thoughts? Hi Corey, Sorry for the late reply. To start, a toolchain isn't the right thing. The toolchain in the ManagedBuild world is used to generate Makefiles in the ManagedBuild process and that isn't being done in the autotools case. You are actually overriding special variables in the configuration step. What is attractive about the toolchain is that it is tied to a CDT configuration and can have preset values. I think we need to do the same here. We need to be able to have a set of canned configurations with different configure overrides. For example, we could have a gprof configuration which set up the flags appropriately for building with gprof support. Right now a user has to do this manually for an autotools project. We can use a tool option handler to accomplish this. Right now we have a tool option called name for the configure tool and use an option handler. The user nevers sees this option. This option handler allows us to recognize when a new configuration is created via the Managed Configuration dialog because we compare the name to the name of the configuration. Anyway, we can use the same mechanism and have a special option that specifies the override parameters. What's nice about this is that the option handler could do stuff like searching the local system for the toolchain for an executable or toolchain, etc...) How we show this to the user could vary. We could simply add a build variable to the default configure command and then set that build variable for each canned configuration. This allows the user to alter it if desired (e.g. user uses a gprof support configuration and then adds a few additional flags to that). What do you think?
(In reply to comment #7) > To start, a toolchain isn't the right thing. The toolchain in the ManagedBuild > world is used to generate Makefiles in the ManagedBuild process and that isn't > being done in the autotools case. You are actually overriding special > variables in the configuration step. What is attractive about the toolchain is > that it is tied to a CDT configuration and can have preset values. > > I think we need to do the same here. We need to be able to have a set of > canned configurations with different configure overrides. For example, we > could have a gprof configuration which set up the flags appropriately for > building with gprof support. Right now a user has to do this manually for an > autotools project. > > We can use a tool option handler to accomplish this. Right now we have a tool > option called name for the configure tool and use an option handler. I'm not clear what you mean by "a tool option called name". Where can I find this code? > The user > nevers sees this option. This option handler allows us to recognize when a new > configuration is created via the Managed Configuration dialog because we > compare the name to the name of the configuration. Anyway, we can use the same > mechanism and have a special option that specifies the override parameters. > What's nice about this is that the option handler could do stuff like searching > the local system for the toolchain for an executable or toolchain, etc...) Can you explain what you mean by "search the local system"? Does that mean search for things like /usr/bin/gcc ? > > How we show this to the user could vary. We could simply add a build variable > to the default configure command and then set that build variable for each > canned configuration. This allows the user to alter it if desired (e.g. user > uses a gprof support configuration and then adds a few additional flags to > that). If the canned configurations can be provided via an extension point, that sounds like a good way to go.
(In reply to comment #8) > (In reply to comment #7) > > To start, a toolchain isn't the right thing. The toolchain in the ManagedBuild > > world is used to generate Makefiles in the ManagedBuild process and that isn't > > being done in the autotools case. You are actually overriding special > > variables in the configuration step. What is attractive about the toolchain is > > that it is tied to a CDT configuration and can have preset values. > > > > I think we need to do the same here. We need to be able to have a set of > > canned configurations with different configure overrides. For example, we > > could have a gprof configuration which set up the flags appropriately for > > building with gprof support. Right now a user has to do this manually for an > > autotools project. > > > > We can use a tool option handler to accomplish this. Right now we have a tool > > option called name for the configure tool and use an option handler. > > I'm not clear what you mean by "a tool option called name". > > Where can I find this code? > In autotools.core, the Managed buildDefinition for Autotools has tools specified for configure and autogen.sh. For configure, the tool adds an option called "name". Since we are not a ManagedBuild project, the tools and their settings are not shown in the C/C++ Build section of the Project Properties dialog. This is why we had to add our own Autotools section with the settings for configure and autogen.sh. For a ManagedBuild project, the tools would just appear in the Settings tab and we wouldn't have to do anything. In addition, the settings would be saved in the .cproject file as opposed to having our own .autotools file. Now, for each tool option, you can specify a special option handler. This handler gets called for major events such as opening a configuration or deleting one. We set up one for "name". It specifies a class that handles this option. <tool command="configure" id="org.eclipse.linuxtools.cdt.autotools.core.tool.configure" isAbstract="false" name="%Tool.configure" natureFilter="both" supportsManagedBuild="false"> <optionCategory id="org.eclipse.linuxtools.cdt.autotools.core.optionCategory.configure.general" name="%OptionCategory.configure.general" owner="org.eclipse.linuxtools.cdt.autotools.core.tool.configure"/> <option applicabilityCalculator="org.eclipse.linuxtools.internal.cdt.autotools.core.configure.AutotoolsOptionValueHandler" category="org.eclipse.linuxtools.cdt.autotools.core.optionCategory.configure.general" id="org.eclipse.linuxtools.cdt.autotools.core.option.configure.name" isAbstract="false" name="%Option.configure.name" resourceFilter="all" valueHandler="org.eclipse.linuxtools.internal.cdt.autotools.core.configure.AutotoolsOptionValueHandler" valueType="string"> The class AutotoolsOptionValueHandler handles the events. We set it up so we can figure out when a new Configuration is being created and copied from an old one. When it is new, we know because the name field will not be set. We set it to be the name of the configuration. When copied, it will have the old name inside so we know which AutotoolsConfiguration to copy from. We could use the same mechanism, perhaps the same class to handle setting the build macro. > > The user > > nevers sees this option. This option handler allows us to recognize when a new > > configuration is created via the Managed Configuration dialog because we > > compare the name to the name of the configuration. Anyway, we can use the same > > mechanism and have a special option that specifies the override parameters. > > What's nice about this is that the option handler could do stuff like searching > > the local system for the toolchain for an executable or toolchain, etc...) > > Can you explain what you mean by "search the local system"? Does that mean > search for things like /usr/bin/gcc ? > IIRC, you wanted this so the user could override the default GNU toolchain being used. Well, if your desired toolchain isn't always at some fixed location and you can't rely on the user's path to be set up, you could conceivably search for the toolchain's location on the system. Purely hypothetical. > > > > How we show this to the user could vary. We could simply add a build variable > > to the default configure command and then set that build variable for each > > canned configuration. This allows the user to alter it if desired (e.g. user > > uses a gprof support configuration and then adds a few additional flags to > > that). > > If the canned configurations can be provided via an extension point, that > sounds like a good way to go. I was hoping it could be done via the existing buildDefinitions, but my experiments don't seem to work as the configurations seem to have to be under one projectType declaration. I will ask on the CDT list to see if there is a way. If not, we could pursue our own extension and we try to create multiple configurations at project creation/conversion. In that case, we could copy the default configuration and set the build macros at that time.
Jeff, Thanks for your very detailed reply. I'm starting to get a better feel for what you are describing now. I found the "Name" option extension you are talking about. One thing that puzzles me, though, is that it doesn't show up in the Configure Settings dialog under configure->General, even though the AutotoolsOptionValueHandler hard-codes the "isOptionVisible" method to always return true. How does that work? As for searching the local system, I understand what you are getting at now. My first thought was that our SDK RPM has as its dependency our toolchain RPM. So that would mean that we can guarantee that the toolchain will be there. However, we only require the most toolchain to be installed, while some of our users will want to use an older toolchain (previously installed) for some projects, and the newer toolchain for other projects. So dynamically searching for existing toolchains is a good general way of handling it. However, I think we shouldn't be building the search paths into the basic autotools plug-in. The paths to search should be provided by extensions. Excerpt from comment #9: "If not, we could pursue our own extension and we try to create multiple configurations at project creation/conversion. In that case, we could copy the default configuration and set the build macros at that time." So the idea is that we have a default configuration for each "toolchain" that we have found on the local system, and when the user does a create, the plug-in copies this default config for the selected "toolchain" to the new project?
(In reply to comment #10) > Jeff, > > Thanks for your very detailed reply. I'm starting to get a better feel for > what you are describing now. > > > I found the "Name" option extension you are talking about. One thing that > puzzles me, though, is that it doesn't show up in the Configure Settings dialog > under configure->General, even though the AutotoolsOptionValueHandler > hard-codes the "isOptionVisible" method to always return true. How does that > work? > It works because there are two different mechanisms. We (Autotools) are the ones that build the Configure Settings dialog and we don't use the buildDefinitions to do this. The CDT doesn't bother to create a settings dialog for the tools because we aren't using Managed Build. Normally, a Settings tab would be created automatically under C/C++->Build > As for searching the local system, I understand what you are getting at now. > My first thought was that our SDK RPM has as its dependency our toolchain RPM. > So that would mean that we can guarantee that the toolchain will be there. > However, we only require the most toolchain to be installed, while some of our > users will want to use an older toolchain (previously installed) for some > projects, and the newer toolchain for other projects. > > So dynamically searching for existing toolchains is a good general way of > handling it. However, I think we shouldn't be building the search paths into > the basic autotools plug-in. The paths to search should be provided by > extensions. That's not a problem. I was just pointing out that the option handler gives us flexibility to do lots of things. > > Excerpt from comment #9: > "If not, we could pursue our own extension and we try to create multiple > configurations at project creation/conversion. In that case, we could copy the > default configuration and set the build macros at that time." > > So the idea is that we have a default configuration for each "toolchain" that > we have found on the local system, and when the user does a create, the plug-in > copies this default config for the selected "toolchain" to the new project? Actually, I was thinking more of there would be an extension that would specify the settings of the build macro that is used by configure. The extension could have an optional class specifier for complicated cases where the flags needed to be calculated or enablement. You could do the calculation there if needed, but you would have one extension per toolchain or flag combination you wanted to make available.
Sorry for the delay in my reply. What you describe sounds like it would work very well for us. Were you able to find any information from the CDT folks?
(In reply to comment #12) > Sorry for the delay in my reply. > > What you describe sounds like it would work very well for us. > > Were you able to find any information from the CDT folks? No reply from the CDT folks, but I did some experiments. I added the following in AutotoolsBuildWizard::createItems() (pt is the Autotools projectType). IConfiguration[] c = pt.getConfigurations(); IConfiguration c0 = pt.createConfiguration(c[0], "blah", "New Configuration"); IToolChain tc0 = c[0].getToolChain(); c0.createToolChain(tc0, "new.tool.id", tc0.getName(), true); This is ust experimenting as we would need to check that the id doesn't exist on the 2nd/3rd time through. With this, I was able to get a "New Configuration" to show up in the list of configurations at creation time and it was checked. It also showed up in the configurations list in the project properties. I am running into a problem when restarting Eclipse as it flags a load error because it finds a new "blah.xxxxx" configuration and this points to it's parent "blah" but that isn't in the .cproject for some reason. Not sure how to fix this at this time as this is obviously outside expected API usage. So, disregarding the .cproject issue, the result is similar to the Debug/Release configurations. Both are shown in the Select Configurations dialog of the C Project wizard and the first is defaulted. If the user unchecks the default configuration, the next one in the list becomes the default, but the unchecked configuration will not show up in the drop-down list for the project. The user can later create a new configuration based on that configuration if switching is desired. Otherwise, the user can switch between the default and other configurations in the list after the wizard completes. Perhaps a project template can be used in conjunction to set a default configuration. I don't know at this time if it will work in conjunction with our dynamic configurations. So, basically a first step. The next step is to set the macro variable (directly, if possible). So, we could have our own extension that gives us a configuration name, and the setting of the override macro. Hopefully I can figure out how to avoid the configuration load error.
Hi Jeff! Now that autotools will be contributed to CDT project, do you think feasible implement feature described here?
(In reply to comment #14) > Hi Jeff! > > Now that autotools will be contributed to CDT project, do you think feasible > implement feature described here? I'm afraid I haven't done any further experimentation on this feature since my last post. I have since added configuration settings for gprof and gcov usage, but they are canned compilation/link options and don't change like your toolchain locations. The initial contribution will simply be a refactoring of the current version of Autotools with some changes to allow old Autotools projects to continue working without having to be converted. There is some work to get just this done and there is the CQ process which must get started ASAP (it requires an initial tarball). The strategy I mentioned still needs to be explored a bit more but I still think it is feasible. Once Autotools is part of the CDT, I probably should revisit to see if it can be done simpler using internal classes (Autotools can be an x-friend as part of the CDT).
