[GRADLE-3063] Unexpected C/C++ private header handling behavior Created: 07/Apr/14  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 0


The Gradle recommended conventions for "private" header files is to place them in the cpp directory next to their implementation files. When I do this, I get unexpected behavior which is dependent on the header file extension (i.e. .h, .hpp) and is incorrect in all cases.

.hpp: When a header file ending in .hpp is placed in the cpp directory, it is included on the g++ command line as if it were a .cpp file. Dependening on the order in which this file appears on the command line can effect the contents of the resulting object file. To reproduce this, create a cpp file with a single function (not a class, just a function). Declare the function in a .hpp file and consume it in a test program. Invoke g++ manually and play with the order in which the .cpp and .hpp are listed on the command line.

.h: When a header file ending in .h is placed in the cpp directory, it is included on the g++ command line as if it were a .cpp file. This results in a precompiled header being generated. This is not necessarily a desired behavior and can result.

In all these cases, it seems the problems would go away if the header files were not included on the command line except when part of a -I flag. While a workaround may be to explicitly exclude *.h, *.hpp from the source set, this seems clumsy. Rather, for the relatively rare case where you want to compile your header file, making the necessary source set adjustments seems appropriate.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:38:55 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.