Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NO_ACTION_MACRO and NO_ACTION_FUNCTION when LINK_TIME_OPTIMIZATION_ENABLE is defined. #8604

Closed
mtei opened this issue Mar 30, 2020 · 7 comments · Fixed by #8663
Closed

NO_ACTION_MACRO and NO_ACTION_FUNCTION when LINK_TIME_OPTIMIZATION_ENABLE is defined. #8604

mtei opened this issue Mar 30, 2020 · 7 comments · Fixed by #8663
Labels

Comments

@mtei
Copy link
Contributor

mtei commented Mar 30, 2020

It appears that NO_ACTION_MACRO and NO_ACTION_FUNCTION have been defined twice. Why is that?

The following changes have been made to #5674

diff --git a/tmk_core/common.mk b/tmk_core/common.mk
index 94f3c2380..221688755 100644
--- a/tmk_core/common.mk
+++ b/tmk_core/common.mk
@@ -208,6 +208,13 @@ ifeq ($(strip $(SHARED_EP_ENABLE)), yes)
     TMK_COMMON_DEFS += -DSHARED_EP_ENABLE
 endif
 
+
+ifeq ($(strip $(LINK_TIME_OPTIMIZATION_ENABLE)), yes)
+    EXTRAFLAGS += -flto
+    TMK_COMMON_DEFS += -DLINK_TIME_OPTIMIZATION_ENABLE
+    TMK_COMMON_DEFS += -DNO_ACTION_MACRO
+    TMK_COMMON_DEFS += -DNO_ACTION_FUNCTION
+endif
 # Bootloader address
 ifdef STM32_BOOTLOADER_ADDRESS
     TMK_COMMON_DEFS += -DSTM32_BOOTLOADER_ADDRESS=$(STM32_BOOTLOADER_ADDRESS)

Nevertheless, the following further changes have been made in #7211

diff --git a/quantum/template/avr/config.h b/quantum/template/avr/config.h
index 304a54ae5..7e4a01449 100644
--- a/quantum/template/avr/config.h
+++ b/quantum/template/avr/config.h
@@ -190,9 +190,12 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
 //#define NO_ACTION_LAYER
 //#define NO_ACTION_TAPPING
 //#define NO_ACTION_ONESHOT
-//#define NO_ACTION_MACRO
-//#define NO_ACTION_FUNCTION
 
+/* disable these deprecated features by default */
+#ifndef LINK_TIME_OPTIMIZATION_ENABLE
+  #define NO_ACTION_MACRO
+  #define NO_ACTION_FUNCTION
+#endif
 /*
  * MIDI options
  */
@mtei mtei added the question label Mar 30, 2020
@vomindoraan
Copy link
Contributor

vomindoraan commented Apr 1, 2020

I can confirm that I'm having trouble compiling some AVR boards with LTO_ENABLE = yes on the latest master.

@vomindoraan
Copy link
Contributor

vomindoraan commented Apr 1, 2020

It appears that these boards don't define the macros conditionally, i.e. they don't check for LTO first.

//#define NO_ACTION_ONESHOT
#define NO_ACTION_MACRO
#define NO_ACTION_FUNCTION

Since this is a common occurrence across many keyboards, keymaps and userspaces, the only sensible solution, in my opinion, is to remove the macro definitions from tmk_core/common.mk.

@mtei
Copy link
Contributor Author

mtei commented Apr 1, 2020

I seem to have misread the contents of quantum/template/avr/config.h.

In quantum/template/avr/config.h, NO_ACTION_* is defined when LINK_TIME_OPTIMIZATION_ENABLE is not defined.

In tmk_core/common.mk b/tmk_core/common.mk, the
LINK_TIME_OPTIMIZATION_ENABLE and NO_ACTION_* are all defined.

As a result, NO_ACTION_* always seems to be defined.

@vomindoraan
Copy link
Contributor

There's still a problem with that. Not all boards, userspaces or keymaps are going to have the #ifndef LINK_TIME_OPTIMIZATION_ENABLE check around #define NO_ACTION_{FUNCTION,MACRO} — and it would be unreasonable to expect them to have it.

Defining NO_ACTION_{FUNCTION,MACRO} in tmk_core/common.mk is a bad solution for this reason. At the time of processing the makefile, there's no way of knowing or checking whether some user code down the line defines those same macros. Making the check mandatory would not only make keyboard/user code less elegant, but it would also make the usage of NO_ACTION_{FUNCTION,MACRO} asymmetric compared to other NO_ACTION_* macros.

@vomindoraan
Copy link
Contributor

For this reason, I think a better solution would be to remove the defines from tmk_core/common.mk:

diff --git a/tmk_core/common.mk b/tmk_core/common.mk
index 4d4272d26..3d0b83a01 100644
--- a/tmk_core/common.mk
+++ b/tmk_core/common.mk
@@ -162,8 +162,6 @@ ifeq ($(strip $(LINK_TIME_OPTIMIZATION_ENABLE)), yes)
     endif
     EXTRAFLAGS += -flto
     TMK_COMMON_DEFS += -DLINK_TIME_OPTIMIZATION_ENABLE
-    TMK_COMMON_DEFS += -DNO_ACTION_MACRO
-    TMK_COMMON_DEFS += -DNO_ACTION_FUNCTION
 endif

 # Search Path

and instead conditionally define NO_ACTION_{MACRO,FUNCTION} in tmk_core/common/action.h:

diff --git a/tmk_core/common/action.h b/tmk_core/common/action.h
index dd22023f9..17f770fa0 100644
--- a/tmk_core/common/action.h
+++ b/tmk_core/common/action.h
@@ -28,6 +28,15 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
 extern "C" {
 #endif

+#ifdef LINK_TIME_OPTIMIZATION_ENABLE
+#    ifndef NO_ACTION_MACRO
+#        define NO_ACTION_MACRO
+#    endif
+#    ifndef NO_ACTION_FUNCTION
+#        define NO_ACTION_FUNCTION
+#    endif
+#endif
+
 /* tapping count and state */
 typedef struct {
     bool    interrupted : 1;

This solution avoids all of the above problems, and further allows the LTO check to be removed from quantum/template/avr/config.h.

@mtei
Copy link
Contributor Author

mtei commented Apr 1, 2020

Tagging @qmk/collaborators

@vomindoraan
Copy link
Contributor

vomindoraan commented Apr 1, 2020

Here's a branch where I have implemented the change:

https://github.com/vomindoraan/qmk_firmware/tree/no_action_macro_function

The following keyboards can be used for testing:

claw44
amj96
georgi
scarletbandana
tetris
pearl
uzu42
clueboard/66_hotswap
jc65/v32a
kbdfans/kbd6x
converter/usb_usb/ble
handwired/xealous/rev1
sentraq/s60_x/default

On master, these don't compile if LTO_ENABLE = yes is set. With this change, they compile correctly.

vomindoraan added a commit to vomindoraan/qmk_firmware that referenced this issue Apr 3, 2020
…O is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).
zvecr pushed a commit that referenced this issue Apr 8, 2020
…#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
HokieGeek pushed a commit to HokieGeek/qmk_firmware that referenced this issue Apr 10, 2020
…qmk#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
violet-fish pushed a commit to violet-fish/qmk_firmware that referenced this issue Apr 12, 2020
…qmk#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
Quarren42 pushed a commit to Quarren42/qmk_firmware that referenced this issue Apr 15, 2020
…qmk#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
kylekuj pushed a commit to kylekuj/qmk_firmware that referenced this issue Apr 21, 2020
…qmk#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
bitherder pushed a commit to bitherder/qmk_firmware that referenced this issue May 15, 2020
…qmk#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
drashna pushed a commit to zsa/qmk_firmware that referenced this issue May 24, 2020
…qmk#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
sowbug pushed a commit to sowbug/qmk_firmware that referenced this issue May 24, 2020
…qmk#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
fdidron pushed a commit to zsa/qmk_firmware that referenced this issue Jun 12, 2020
…qmk#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
turky pushed a commit to turky/qmk_firmware that referenced this issue Jun 13, 2020
…qmk#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
jakobaa pushed a commit to jakobaa/qmk_firmware that referenced this issue Jul 7, 2020
…qmk#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
thorstenweber83 pushed a commit to thorstenweber83/qmk_firmware that referenced this issue Sep 2, 2020
…qmk#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
BorisTestov pushed a commit to BorisTestov/qmk_firmware that referenced this issue May 23, 2024
…qmk#8663)

* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled

Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (qmk#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).

* Remove LTO checks in templates

Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.

* Update LTO_ENABLE docs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants