Community
Participate
Working Groups
Build Identifier: CVS Our toolchain is based on GNU linker and adds some tools and requires the executable to be linked against our libraries. To achive this we created the tool based on cdt.managedbuild.tool.gnu.cpp.linker.exe.debug that has libs and libPaths options with the custom applicability calculator so they do not show up in the linker settings UI but are still included in linker command-line arguments. Those values are still shown on the appropriate tabs of the "C/C++ General"/"Paths and Symbols" preference page. Another problem is that there is a harmless error log entry stating we have several options of the same kind (see BuildEntryStorage.java(v1.19):611. It looks like this storage should check option applicability. Reproducible: Always Steps to Reproduce: 1.Declare a custom option of the "libs" type and set its value in the plug-in manifest. 2. Run the IDE and check the preference page. 3. Library is shown on the page.
There's an easy workaround: - Don't declare your IOption as a lib / libpath type, just declare it as a string list. This will prevent the paths from being sent to cdt.core _and_ prevent them from being dispalyed in the Paths & Symbols page. (In reply to comment #0) > Another problem is that there is a harmless error log entry stating we have > several options of the same kind (see BuildEntryStorage.java(v1.19):611. It's not harmless. Certain options can be set either using API in cdt.core or in mbs.core. There's a mapping between options of the same 'type'. If there's more than one IOption for a given cdt.core language setting entry, then cdt.core will only see some of the options values. This may not matter for libs and libPaths, but it does matter for preprocessor symbols and include search paths. See also bug 340660. It seems like you don't want cdt.core to know about these paths, so I recommend the workaround above.
The problem is that I need cdt.core to use these values when linking the application. I don't want the user to know about them. Isn't it the reason for IOptionApplicability::isOptionVisible method? What I have right now is inconsistent UI - the library is not shown on the linker settings page (that is desirable behavior) but is still shown on the project paths property page that shows values derived from linker settings. That error should not really appear in my scenario as there should be single option editable by user - default linker libs/libPaths. The option I introduced (for provided library) should not be visible to the user and should not be usable - its value is coming from plugin manifest or Java code.
(In reply to comment #2) > The problem is that I need cdt.core to use these values when linking the > application. I don't want the user to know about them. Isn't it the reason for > IOptionApplicability::isOptionVisible method? Why does cdt.core need to know? MBS does the linking. If you don't want cdt.core to show the options, then don't pass them to it. A string list option will be applied correctly. > That error should not really appear in my scenario as there should be single > option editable by user - default linker libs/libPaths. The option I introduced > (for provided library) should not be visible to the user and should not be > usable - its value is coming from plugin manifest or Java code. Well don't define the option as LIBRARIES / LIB_PATHS. Did you try that?
> Why does cdt.core need to know? MBS does the linking. If you don't want cdt.core to show the options, then don't pass them to it. A string list option will be applied correctly. Currently our toolchain is a thin layer on top of GNU toolchain hence we are able to reuse makefile generation code from CDT. That code will only discover libraries from the options that have "libs" path. Basically, this issue is the only one that we encountered. > Well don't define the option as LIBRARIES / LIB_PATHS. Did you try that? Then they will not be passed to linker.
(In reply to comment #4) > Currently our toolchain is a thin layer on top of GNU toolchain hence we are > able to reuse makefile generation code from CDT. That code will only discover > libraries from the options that have "libs" path. Basically, this issue is the > only one that we encountered. Seriously, just create a new option that's identical to CDT's built-in libs options except with a type of string list. > > Well don't define the option as LIBRARIES / LIB_PATHS. Did you try that? > > Then they will not be passed to linker. Did you try it?
> Did you try it? Yes. I will close this bug as "wontfix" as we seem to be the only adopters facing this problem and we chose a bit different approach so this issue is no longer a concern for us.
If this is a bug lets keep it open even if you are the only adopters. If somebody has a need to rework the code in future, this would be a record of a useful case to consider.
(In reply to comment #7) > If this is a bug lets keep it open even if you are the only adopters. If > somebody has a need to rework the code in future, this would be a record of a > useful case to consider. If the reporter believes it's a bug then it would be good if they could provide a plugin.xml demonstrating the issue. I don't see how the paths will end up in the core.ui if they use the instructions outlined in comment 1. From where I sit, this is wontfix.
(In reply to comment #6) > > Did you try it? > > Yes. I don't see how it wouldn't work. There are _very_ few special options which are passed back to cdt.core. All the rest are handled internally to the mbs. There's no reason your mbs option should be any different.
