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

<command-line>: error: macro names must be identifiers #2174

Open
12 tasks
MariwanJ opened this issue Jan 2, 2024 · 11 comments
Open
12 tasks

<command-line>: error: macro names must be identifiers #2174

MariwanJ opened this issue Jan 2, 2024 · 11 comments
Labels

Comments

@MariwanJ
Copy link

MariwanJ commented Jan 2, 2024

What seems to be the problem?
Extra -D in the make file (linux) that causes the issue. This happens due to "defines".

DEFINES += -D_CRT_SECURE_NO_WARNINGS -D

What did you expect to happen?
That -D shouldn't be there when there is no other defines available. But premake5 added to the end of the previous defines text.

What have you tried so far?
I have a library that include another vendor library. This library will be static-linked to the main project. I can send the whole project if that is required.

How can we reproduce this?
If you have defines inside the library (lua script), you will get the extra -D in the make file for the library. Removing the -D will compile just fine. This does not affect Windwos 10.

  • Visual Studio 2022 (vs2022)
  • Visual Studio 2019 (vs2019)
  • Visual Studio 2017 (vs2017)
  • Visual Studio 2015 (vs2015)
  • Visual Studio 2012 (vs2012)
  • Visual Studio 2010 (vs2010)
  • Visual Studio 2008 (vs2008)
  • Visual Studio 2005 (vs2005)
  • [X ] GNU Makefile (gmake)
  • GNU Makefile 2 (gmake2)
  • XCode (xcode)
  • Codelite
  • Other (Please list below)

What version of Premake are you using?
premake5

Anything else we should know?
no

@MariwanJ MariwanJ added the bug label Jan 2, 2024
@nickclark2016
Copy link
Member

Can you confirm if this is a bug on gmake2? gmake is effectively deprecated at this point in time.

@MariwanJ
Copy link
Author

MariwanJ commented Jan 2, 2024

yes it was gmake.
I tried even gmake2 .. the same.
issue

@nickclark2016
Copy link
Member

nickclark2016 commented Jan 2, 2024

Can you share your premake file used to generate this? It's something like really should have been caught in our test suite, so I'm a bit confused why this is happening.

@MariwanJ
Copy link
Author

MariwanJ commented Jan 2, 2024

ProjectPathConfig.zip
Please find the attached zip file. It is a dummy project that I try to get sub library included in another library. I regenerated the make files with the issue.
Notice that it appears only under the debug section

@nickclark2016 nickclark2016 added question and removed bug labels Jan 2, 2024
@nickclark2016
Copy link
Member

This is an invalid usage issue. In your debug configuration in the PPCL project, you're adding a "" define to the list. defines declarations append to each other in the underlying list.

@MariwanJ
Copy link
Author

MariwanJ commented Jan 2, 2024

I don't think that is causing the issue. I have that so it will cover both linux and windows. With no filter it should be applied to all. Remove it and see the result. I had in the other hand an extra ""_CRT_SECURE_NO_WARNINGS" defined under windows filter which is bug and wrong.

@nickclark2016
Copy link
Member

defines "" is wrong, since it just adds an empty "" to the existing list. It does not reset the list of defines. You also have a "_CRT_SECURE_NO_WARNINGS" in an unfiltered context, which is why you're seeing it an extra time in the windows filter. It is expected behavior, as it's a list of defines, not a set.

@MariwanJ
Copy link
Author

MariwanJ commented Jan 2, 2024

Ok that "defines" is left there for future usage. Shouldn't that be ignored when there is nothing? I don't think that should cause an issue. You prepare your filters, defines ..etc for future usage and premake5 should know when to add or not IMHO.

@nickclark2016
Copy link
Member

As it currently stands, I don't think it's a bug in premake as written, as we don't specify that an empty string is ignored in the documentation. The case can definitely be made to add that functionality, but I wouldn't classify it as a bug currently.

@MariwanJ
Copy link
Author

MariwanJ commented Jan 2, 2024

Ok. thanks for clarifying my lua scripts.

@nickclark2016
Copy link
Member

No problem. This is definitely something worth reviewing on our end, to figure out if it's functionality that should be added or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants