Bug Hunting Session
Bug 97046 - ensure build system variables start with gb_ unless there are very, very good reasons not to
Summary: ensure build system variables start with gb_ unless there are very, very good...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyBeginner, easyHack, skillScript, topicCleanup
Depends on:
Blocks:
 
Reported: 2016-01-11 16:22 UTC by Björn Michaelsen
Modified: 2017-02-14 08:57 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Michaelsen 2016-01-11 16:22:26 UTC
The "new" gbuild build system is picking up some age -- and some things bitrot. 

Initially gbuild had all its variables prefixed/namespaced with gb_... unless this was unavoidable. The rationale is that gb_ is not a lot to write extra and this:
- prevents conflicts with shell environment variables, and thus prevents:
-- conflicts with any of the tools using the environment in the build
-- conflicts with environment vars from the users shell bleeding into the build
- is more grep-able

So unless there are very, very good reasons (like an external tool we are using in the build being hardcoded to a variable name) for a build system variable not to start with a gb_ prefix, it should. As a bonus, the var should ideally continue showing what part of the build system it belongs to (e.g. gb_CppunitTest_... or gb_Jar_...) to avoid hard to debug overlaps there as we are unfortunately in a project global namespace.

Code pointer: solenv/gbuild/
Comment 1 Robinson Tryon (qubit) 2016-02-18 14:51:38 UTC Comment hidden (obsolete)