Feature changed by: Susanne Oberhauser (froh) Feature #309556, revision 3 Title: create code dependency information with instrumented gcc Requested by: Susanne Oberhauser (froh) Description: gcc >=4.5 allows for plugins the dehydra/treehydra gcc plugins have access to gcc parse trees and can thus in theory emit symbol dependency annotations for source code:  where is which symbol used, where is which function used, where are they defined? And this does not come from some parsed guess but from the real build, with the real CFLAGS, for the real code. This symbol level dependency information can then be used for static code analysis, and if compared between builds it can be used to make the dynamics not of source changes but of dependency changes tangible. + Test Case: + manual: manually build some code with using the instrumented gcc and + appropriately set CFLAGS; get symbol dependency information files along + each generated object. packaged: build a package with the instrumented + gcc and CFLAGS set to use the instrumentation.  get an additional + package (like debuginfo or debougsource) that contains the generated + symbol dependency information. + Use Case: + legal: dependency information can be used to see which interfaces or + files actually have been used for a program API analysis: dependency + information on interfaces allows to tell which interfaces change a lot, + which ones don't which ones are used a lot and which ones aren't. -- openSUSE Feature: https://features.opensuse.org/309556

Feature changed by: Juergen Weigert (jnweiger) Feature #309556, revision 5 Title: create code dependency information with instrumented gcc Requested by: Susanne Oberhauser (froh) Developer: (Novell) Description: gcc >=4.5 allows for plugins the dehydra/treehydra gcc plugins have access to gcc parse trees and can thus in theory emit symbol dependency annotations for source code:  where is which symbol used, where is which function used, where are they defined? And this does not come from some parsed guess but from the real build, with the real CFLAGS, for the real code. This symbol level dependency information can then be used for static code analysis, and if compared between builds it can be used to make the dynamics not of source changes but of dependency changes tangible. Test Case: manual: manually build some code with using the instrumented gcc and appropriately set CFLAGS; get symbol dependency information files along - each generated object. packaged: build a package with the instrumented - gcc and CFLAGS set to use the instrumentation.  get an additional - package (like debuginfo or debougsource) that contains the generated - symbol dependency information. + each generated object. + packaged: build a package with the instrumented gcc and CFLAGS set to + use the instrumentation.  get an additional package (like debuginfo or + debougsource) that contains the generated symbol dependency + information. Use Case: legal: dependency information can be used to see which interfaces or - files actually have been used for a program API analysis: dependency - information on interfaces allows to tell which interfaces change a lot, - which ones don't which ones are used a lot and which ones aren't. + files actually have been used for a program. This is valuable input for + deriving the license situation of binary packages, given a file-by-file + source code review. + API analysis: dependency information on interfaces allows to tell + which interfaces change a lot, which ones don't which ones are used a + lot and which ones aren't. -- openSUSE Feature: https://features.opensuse.org/309556