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

forceinclude option not working properly #2257

Open
4 of 13 tasks
edo9300 opened this issue Sep 23, 2024 · 3 comments
Open
4 of 13 tasks

forceinclude option not working properly #2257

edo9300 opened this issue Sep 23, 2024 · 3 comments
Labels
documentation Missing, incorrect, or inadequate documentation.

Comments

@edo9300
Copy link

edo9300 commented Sep 23, 2024

What seems to be the problem?
I'm using premake with a project that has a structure like this

test
├── premake5.lua
└── subproject
    ├── forced-header.h
    ├── premake5.lua
    └── src
        └── source.cpp

this is the content of the topmost premake5.lua file

workspace "test"
location "build"
language "C++"
objdir "obj"
configurations { "Debug", "Release" }

include "subproject"

this is the content of the second premake5.lua

project "subproject"
	kind "StaticLib"
	files { "src/*.cpp" }	
	forceincludes { "forced-header.h" }

My intention is to have forced-header.h be included in all the files in the src folder, and as the docs say Paths should be specified relative to the currently running script file.
Instead, the generated solutions don't work as expected, with the gmake2 and msvc targets also differing in their behaviour:

  • In the msvc target, the forceinclude is checked from the source file's current path, and to have it be found by the compiler, it has to be passed as forceincludes { "../forced-header.h" } to premake
  • In the gmake2 target, the search path is the path the generated makefile is in, so in this case the build directory, and to have it found it has to be passed as forceincludes { "../subproject/forced-header.h" } to premake

What did you expect to happen?
The function behaves as described and the targets properly find the header, or at least "break" in a consistent way

How can we reproduce this?

  • 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)
  • GNU Makefile (gmake)
  • GNU Makefile 2 (gmake2)
  • XCode (xcode)
  • Codelite
  • Other (Please list below)

What version of Premake are you using?
premake5 (Premake Build Script Generator) 5.0.0-beta2

@edo9300 edo9300 added the bug label Sep 23, 2024
@richard-sim
Copy link
Contributor

richard-sim commented Sep 30, 2024

I think the issue is that you're not adding test/subproject/ to the include search path, i.e.:

project "subproject"
	kind "StaticLib"
	files { "src/*.cpp" }	
	forceincludes { "forced-header.h" }
        includedirs { "." }

/FI (MSVC) and --include (gcc, clang) basically just prepend the source files with #include "forced-header.h", and have no additional magic to find that file beyond how it finds any other include file (well, other than GCC will first search the preprocessors working directory for forced includes... for reasons. Hence the difference you see between MSVC and gmake2).

@edo9300
Copy link
Author

edo9300 commented Sep 30, 2024

Yeah, that seemed to be it, I guess the docs need to be updated in case to specify that the folder must be aging the include directories

@nickclark2016
Copy link
Member

A bit late to the party, but I think in terms of functionality, this is what we want. We could definitely update the docs to specifically call out that the forced include must be on the defined include directories paths.

@nickclark2016 nickclark2016 added documentation Missing, incorrect, or inadequate documentation. and removed bug labels Nov 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Missing, incorrect, or inadequate documentation.
Projects
None yet
Development

No branches or pull requests

3 participants