OMNeT++/OMNEST Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000987OMNeT++command line toolspublic2017-01-13 12:492017-01-27 14:08
Assigned Torhornig 
PrioritynormalSeverityfeatureReproducibilityhave not tried
PlatformOSOS Version
Product Version5.1 
Target VersionFixed in Version 
Summary0000987: opp_makemake generated makefiles should use -isystem
DescriptionIt would be better to use -isystem instead of -I for all dependent projects and for the main omnetpp include, too.

Projects are never interested in the warnings of the project they depend on as they would not be able to fix them anyway.
TagsNo tags attached.
Attached Filespatch file icon [^] (1,123 bytes) 2017-01-14 13:50 [Show Content]
patch file icon opp_makemake.patch [^] (2,484 bytes) 2017-01-14 13:50 [Show Content]

- Relationships

-  Notes
till (reporter)
2017-01-14 13:54

I provided two patches for nedtool and makemake to make them aware of -isystem. For the builds on the console that works perfectly for me. I have not spent time to also implement that in metamakemake for the IDE. Obviously I did not want to setup a build system for the IDE plugins. But I think there should not be too many changes necessary to add that in the IDE as well.
rhornig (administrator)
2017-01-16 15:46

I did a bit research and it seems that not all compilers support the -isystem option. (IBM xLC, SUnStudio does not and the Intel compiler supports it only on Linux and macOS). I'm a bit hesitant to introduce this option as it would break compatibility with those compilers. While they are rarely used we still woul dlove to keep the makefiles as generic as possible.

A possible solution would be also to leave the generator as is (i.e. using -I) and instead you should add for example -isystem ../inet/src in a makefrag file. That would turn the inet/src directory to system include even if it was also added as a -I. This would give greater control over which folders are actually considered to be system ones. Thoughts?
till (reporter)
2017-01-16 16:00

Is it possible to use those (rare) compilers from the IDE? If not, it still makes sense to have metamakemake generate includes with -isystem. If it is possible to have those compilers in the IDE, why not generate -isystem only for gcc and clang in the IDE

For builds from the command line it would always be the users choice how to invoke app_makemake (with -I or -isystem). For those projects with a root folder makefile with "makefiles" target it would even be possible to use -isystem only when gcc or clang was detected. Nevertheless it is necessary that nedtool and opp_makemake recognise -isystem as a valid include path, right?
rhornig (administrator)
2017-01-27 13:02

The IDE is pretty agnostic in regards of the used compiler. In fact the IDE does not know at all what compiler is used. It just calls the generated makefile and that's it. Testing for different compilers inside the generated makefile (or in is a call for trouble as makefiles does not have the necessary tools to correctly detect the compiler itself. Detection could be done in the configure script, but that is not the main concern.

Adding the -isystem support would cause a lot of issues. It's relatively easy to add it to opp_makemake. On the IDE side, you have to be able to configure both -I and -isystem falgs which would require additional dialog elements. Or just have a limited functionality where you can add only -I manually, but all projects used, would be added as -isystem. Though I fear it would not be flexible enough.

There is also a requirement that you should be able to create *exactly* the same makefile both from the IDE and the command line.

A different *much* simpler solution would be to add the directories you need to treated as system in the 'makefrag' file. That would immediately satisfy all requirements. Would you consider adding '-isystem /dep/project/include' in the makefrag file as an acceptable solution? This has zero implementation cost and the trick could be mentioned somewhere in the manual (so minimal documentation cost).
till (reporter)
2017-01-27 13:31

The solution with makefrag might work. But I see two things that are necessary:
- First of all, I would have to know the path to the referenced project, can I be sure that I always have a variable such as "INET_PROJ"?
- If a referenced project is only needed for certain features I would have to add a construct that only adds -isystem if a certain feature is selected.

I think I can work with that solution.
rhornig (administrator)
2017-01-27 14:08

1. Yes PROJECTNAME_PROJ is defined in the makefile for all referenced projects so you can use that variable in makefrag.

2. If you check the current INET master's makefrag file you will find an example how to check feature enablement in a makfile. In fact TCP_NSC feature does exactly need this (add some extra include dirs). Something like this:

WITH_FEATURE := $(shell (cd .. && ./inet_featuretool -q isenabled FEATURE_ID && echo enabled) )
ifeq ($(WITH_FEATURE), enabled)
  INCLUDE_PATH += -isystem ../dep_project/include

- Issue History
Date Modified Username Field Change
2017-01-13 12:49 rhornig New Issue
2017-01-13 12:50 rhornig Summary opp_makemake generated makefiles shoudl use -isystem => opp_makemake generated makefiles should use -isystem
2017-01-14 13:50 till File Added:
2017-01-14 13:50 till File Added: opp_makemake.patch
2017-01-14 13:54 till Note Added: 0001264
2017-01-16 15:46 rhornig Note Added: 0001266
2017-01-16 15:48 rhornig Assigned To => rhornig
2017-01-16 15:48 rhornig Status new => feedback
2017-01-16 16:00 till Note Added: 0001267
2017-01-27 13:02 rhornig Note Added: 0001270
2017-01-27 13:02 rhornig Status feedback => assigned
2017-01-27 13:31 till Note Added: 0001274
2017-01-27 14:08 rhornig Note Added: 0001275

Copyright © 2000 - 2022 MantisBT Team
Powered by Mantis Bugtracker