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: RESOLVED FIXED
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: target:7.3.0 target:7.4.0
Keywords: difficultyBeginner, easyHack, skillScript, topicCleanup
Depends on:
Blocks:
 
Reported: 2016-01-11 16:22 UTC by Björn Michaelsen
Modified: 2022-01-23 16:58 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


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
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
[NinjaEdit]
Comment 2 Buovjaga 2021-02-25 07:16:26 UTC
Björn: it seems to me that this task is obsolete. I did

find solenv/gbuild -name '*.mk' -exec grep --color 'define [^g]' {} +

and there isn't really anything to do.

Can you confirm?
Comment 3 Michael Stahl (allotropia) 2021-11-04 09:43:50 UTC
variables can be defined also with "=" and ":=" not just "define"
Comment 4 Michael Stahl (allotropia) 2021-11-04 09:47:38 UTC
although, most of the "="/":=" are target local variables, that are preceded by a makefile target, i.e. they are not global so shouldn't be a problem.
Comment 5 Commit Notification 2021-11-04 09:48:54 UTC
Sabyasachi Bhoi committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3829c0c7db8768ca05f148e8f5c271ddb56d5bae

Resolves: tdf#97046 ensure build system variables start with gb_

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Michael Stahl (allotropia) 2021-11-04 10:43:57 UTC
... okay i think these are the only ones that make sense to replace:

solenv/gbuild/platform/com_MSC_class.mk:MSC_SUBSYSTEM_VERSION=$(COMMA)$(if $(fil
ter AARCH64,$(CPUNAME)),6.02,6.01)
solenv/gbuild/extensions/pre_MergedLibsList.mk:MERGE_LIBRARY_LIST := \
solenv/gbuild/Output.mk:KNOWN_TERM:=Eterm aterm gnome kterm linux putty rxvt rxv
t-unicode screen xterm xterm xtermc cygwin

there's a bunch more that are meant to be set on the make commandline, best not to change those.
Comment 7 Commit Notification 2022-01-23 16:55:41 UTC
Arjun committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1cc2690fe2f87e8acce4e9b4e0cb533fda26e295

tdf#97046 prefix gb_ to system variables

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.