Better Conan support (official conan member)

[perseoGI]

Greetings,

I’m part of the Conan-io team, and while reviewing our Premake generator, I encountered some issues and have a few questions.

I’m opening this thread as a centralized place to discuss our integration. I’m completely new to Premake, but I find it very interesting and promising. We want to provide great support for your build system and make it easier for users to integrate Conan with Premake.

For those unfamiliar with Conan, it is an open-source C/C++ package manager that has had a significant impact on both open-source projects and enterprise environments.

Conan provides “generators,” which, depending on the upstream build tool used, allow wrapping the project’s configuration and build process. This helps automate compilation and linking, not just for the project itself but also for its dependencies.

A contributor has implemented a Premake generator, but it is still incomplete and has some limitations.

Generator example

This generator essentially works as follows:

1. Let’s start with a basic Premake example:

workspace "HelloWorld"
   configurations { "Debug", "Release" }

project "HelloWorld"
   kind "ConsoleApp"
   language "C++"
   targetdir "bin/%{cfg.buildcfg}"
   files { "**.h", "**.cpp" }

   filter "configurations:Debug"
      defines { "DEBUG" }
      symbols "On"

   filter "configurations:Release"
      defines { "NDEBUG" }
      optimize "On"

2. We need our project to depend on, for example, fmt/11.1.3. We can use Conan for this purpose:

from conan import ConanFile
from conan import ConanFile
from conan.tools.files import copy, chdir 
from conan.tools.layout import basic_layout
from conan.tools.premake import Premake, PremakeDeps
import os

class Pkg(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    name = "pkg"
    version = "1.0"
    exports_sources = '*'

    def layout(self):
        basic_layout(self, src_folder="src")

    def requirements(self):
        self.requires("fmt/11.1.3")

    def generate(self):
        deps = PremakeDeps(self)
        deps.generate()

    def build(self):
        with chdir(self, self.source_folder):
            premake = Premake(self)
            premake.arguments = {"scripts": "../build-release/conan"}
            premake.configure()
            if self.settings.os != "Windows":
                build_type = str(self.settings.build_type)
                self.run(f"make config={build_type.lower()} -j")

    def package(self):
        copy(self, "*.h", os.path.join(self.source_folder, "include"), os.path.join(self.package_folder, "include", "pkg"))
        for lib in ("*.lib", "*.a"):
            copy(self, lib, self.source_folder, os.path.join(self.package_folder, "lib"), keep_path=False)

Note: The above conanfile.py might be incomplete or incorrect—it’s just a quick mockup.

With the following source code:

#include <fmt/printf.h>

int main() {
   const std::string thing("World");
   fmt::print("PRINT: Hello {}!\n", thing);
}

3. Using Conan, we can install our dependencies. Since we are declaring a Premake generator, we will end up with some .lua files that define the targets to link with.

$ conan install . --build=missing

$ tree build-release                                                                                                          
build-release
└── conan
    ├── conan_fmt.premake5.lua
    ├── conan_fmt_vars_release_armv8.premake5.lua
    ├── conan_ninja.premake5.lua
    ├── conan_ninja_vars_release_armv8.premake5.lua
    ├── conanbuild.sh
    ├── conanbuildenv-release-armv8.sh
    ├── conandeps.premake5.lua
    ├── conanrun.sh
    ├── conanrunenv-release-armv8.sh
    ├── conanutils.premake5.lua
    ├── deactivate_conanbuild.sh
    └── deactivate_conanrun.sh

The files we want to focus on is conandeps.premake5.lua and conan_fmt_vars_release_armv8.premake5.lua:

• conan_fmt_vars_release_armv8.premake5.lua:

#!lua

include "conanutils.premake5.lua"

t_conandeps = {}
t_conandeps["release_armv8"] = {}
t_conandeps["release_armv8"]["fmt"] = {}
t_conandeps["release_armv8"]["fmt"]["includedirs"] = {"/Users/perseo/.conan2/p/b/fmtf8f3c9e2307e1/p/include"}
t_conandeps["release_armv8"]["fmt"]["libdirs"] = {"/Users/perseo/.conan2/p/b/fmtf8f3c9e2307e1/p/lib"}
t_conandeps["release_armv8"]["fmt"]["bindirs"] = {"/Users/perseo/.conan2/p/b/fmtf8f3c9e2307e1/p/bin"}
t_conandeps["release_armv8"]["fmt"]["libs"] = {"fmt"}
t_conandeps["release_armv8"]["fmt"]["system_libs"] = {}
t_conandeps["release_armv8"]["fmt"]["defines"] = {}
t_conandeps["release_armv8"]["fmt"]["cxxflags"] = {}
t_conandeps["release_armv8"]["fmt"]["cflags"] = {}
t_conandeps["release_armv8"]["fmt"]["sharedlinkflags"] = {}
t_conandeps["release_armv8"]["fmt"]["exelinkflags"] = {}
t_conandeps["release_armv8"]["fmt"]["frameworks"] = {}

if conandeps == nil then conandeps = {} end
conan_premake_tmerge(conandeps, t_conandeps)

As it can be seen, this file is an autogenerated conan file which has the information of our fmt compiled library, where are the include files, the libs, etc located in the system.

• conandeps.premake5.lua:

#!lua
include "conan_fmt.premake5.lua"
include "conan_ninja.premake5.lua"

function conan_setup_build(conf, pkg)
    if conf == nil then
        filter { "configurations:release", "architecture:armv8" }
            conan_setup_build("release_armv8")
        filter {}
    elseif pkg == nil then
        for k,v in pairs(conandeps[conf]) do
            conan_setup_build(conf, k)
        end
    else
        includedirs(conandeps[conf][pkg]["includedirs"])
        bindirs(conandeps[conf][pkg]["bindirs"])
        defines(conandeps[conf][pkg]["defines"])

    end
end


function conan_setup_link(conf, pkg)
    if conf == nil then
        filter { "configurations:release", "architecture:armv8" }
            conan_setup_link("release_armv8")
        filter {}
    elseif pkg == nil then
        for k,v in pairs(conandeps[conf]) do
            conan_setup_link(conf, k)
        end
    else
        libdirs(conandeps[conf][pkg]["libdirs"])
        links(conandeps[conf][pkg]["libs"])
        links(conandeps[conf][pkg]["system_libs"])
        links(conandeps[conf][pkg]["frameworks"])

    end
end


function conan_setup(conf, pkg)
    conan_setup_build(conf, pkg)
    conan_setup_link(conf, pkg)
end

This file defines a conan_setup function which will be in charge of defining in the proper premake way, the libs, bins, etc of our dependencies (in this case, fmt)

4. Finally, to use this dependencies, we will need to modify our premake5.lua file:

include("conandeps.premake5.lua") -- Script where our conan_setup function is defined

workspace "HelloWorld"
   configurations { "Debug", "Release" }

project "HelloWorld"
   kind "ConsoleApp"
   language "C++"
   targetdir "bin/%{cfg.buildcfg}"
   files { "**.h", "**.cpp" }
   conan_setup()                                    -- Call conan setup

   filter "configurations:Debug"
      defines { "DEBUG" }
      symbols "On"

   filter "configurations:Release"
      defines { "NDEBUG" }
      optimize "On"

5. If our configuration is right, weather if we want to invoke premake directly or using conan

$ premake5 --scripts=../build-release/conan gmake gmake
$ make config=release -j 

or

$ conan build .

We will successfully build our source code using a dependency brought from Conan Center Index

Problems and questions

1. Architecture Support for macOS M-Chip (armv8)
   I am using macOS with an M-series chip, and Conan detects the architecture as armv8. However, this architecture does not appear to be supported in Premake’s predefined architectures (Premake architecture documentation).
   Because of this, our generator does not work automatically on these machines. I haven’t found a way to pass --arch=armv8 to Premake. Could you consider supporting this architecture or allowing users to define a custom architecture?

2. Automated Toolchain Integration (Similar to CMake)
   CMake allows defining toolchains that load automatically before/after parsing the main CMakeLists.txt file without modifying the original build script.
   This is a great feature because it lets users integrate Conan without altering existing CMake scripts. I’ve searched Premake’s documentation for a similar feature—something like a script injection capability—but couldn’t find anything.
   The lack of such a feature forces us to patch upstream recipes that use Premake, requiring us to modify the premake5.lua file directly.

3. Defining the Build Location Outside premake5.lua
   Related to the previous point: Conan organizes folders (source_folder, build_folder, etc.), and it would be great if Premake allowed specifying the build location from the CLI or via script injection, without modifying premake5.lua.
   Is there a way to achieve this in Premake? I couldn’t find one in the latest Premake 5 release.

4. Configuring cppdialect Externally
   In other Conan generators, Conan defines the C++ standard. However, with Premake, it seems we must modify premake5.lua manually to set cppdialect.
   Again, a way to inject this information externally—without modifying premake5.lua—would be very beneficial.

5. Disabling Specific Projects in a Premake Workspace
   Take a look at this project: yojimbo.
   I don’t know if this project follows best practices for Premake, but I couldn’t find a way to disable specific test projects. In Conan Center Index, we do not compile upstream tests (as that is the responsibility of the upstream project).
   Is there an official way to disable specific projects using Premake?

Proposal: Automatic Toolchain Loading for Premake

To summarize, consider implementing a way to automatically load a “Premake toolchain” file that could be generated by external tools like Conan.

This toolchain file could define:

• The C++ standard (cppdialect)
• The build location
• Include directories, library directories, binary directories, etc., for dependencies

Such a feature would significantly improve Conan’s integration with Premake while keeping build scripts clean and unmodified.

Thank you very much for your time and your amazing project ❤️

[nickclark2016]

So I'll try to address these one by one:

1. For MacOS, does the existing ARM64 architecture not work? We currently have the individual variants of ARM family architectures spelled out specifically for Android dev. If not, I'll put this high on our todo list for a coming release.

2. A toolchain file is something that we have talked about internally, but we have not had a strong use case to develop it. This seems like as good a time and reason as any to actually do something about it and implement one. Currently, we have a mechanism to run a system script before the main script is evaluated, but the main script will overwrite any values specified by that (not doing what is needed in Conan's use case). A toolchain file will need to be applied after the initial project configuration so overrides are set properly.

3. I believe this could also be handled via the toolchain file, but having a CLI argument for specifying a default would not be something difficult to go implement.

4. See comments on 2 and 3

5. We have no current mechanism to disable projects. This is something that would need to be investigated.

Overall, I think these are changes that are worth at a minimum investigating from our end (personal opinion: and implementing).

[perseoGI]

Hi @nickclark2016!
Thank you very much for your quick response!

I'm pretty happy to see that we would move this forward!
I think a good and easy to use integration with conan could benefit both of the projects!

1. In conan we have a large list of supported architectures, see docs and source code. Actually, arm64 is more or less the same than armv8 but by default, conan detects this kind of machines as armv8 and as arm64 is not part of the conans default architectures, users may need to define (as I have done) a settings_user.yml with following content:

arch: [arm64]

and call conan this way:

$ conan install . --build=missing --settings '&:arch=arm64'

This is not a problem nor an issue, but it might be worth to take a look and think about the arch values currently supported!

2. I've been making some tests emulating a "framework" that could be easily generated by conan, the idea is to modify minimally the upstream build scripts:

This could be a really basic premake5.lua script:

include("conantoolchain.premake5.lua")   --  This is still needed due to missing toolchain functionality on premake (yet)

workspace "HelloWorld"
   configurations { "Debug", "Release" }

project "HelloWorld"
   kind "ConsoleApp"
   language "C++"

   files { "**.h", "**.cpp" } 

   filter "configurations:Debug"
      defines { "DEBUG" }
      symbols "On"

   filter "configurations:Release"
      defines { "NDEBUG" }
      optimize "On"

And this could be a "conan premake toolchain" generated file:

include("conandeps.premake5.lua")

workspace "HelloWorld"
   location "../build-release"
   cppdialect "C++20"
   location "../build-release"
   targetdir  "../build-release"
   conan_setup()

This is working fine and it is creating the objects and binaries where should:

$ tree                                                                                                                                   
.
├── build-release
│   ├── HelloWorld
│   ├── HelloWorld.make
│   ├── Makefile
│   ├── conan
│   │   ├── conan_fmt.premake5.lua
│   │   ├── conan_fmt_vars_release_arm64.premake5.lua
│   │   ├── conanbuild.sh
│   │   ├── conanbuildenv-release-arm64.sh
│   │   ├── conandeps.premake5.lua
│   │   ├── conanrun.sh
│   │   ├── conanrunenv-release-arm64.sh
│   │   ├── conanutils.premake5.lua
│   │   ├── deactivate_conanbuild.sh
│   │   ├── deactivate_conanbuildenv-release-arm64.sh
│   │   └── deactivate_conanrun.sh
│   ├── metadata
│   └── obj
│       └── Release
│           ├── hello.d
│           └── hello.o
├── conanfile.py
└── src
    ├── conantoolchain.premake5.lua
    ├── hello.cpp
    ├── premake5
    └── premake5.lua

3. Having an easy API to interact with the project from CLI could be really good, I guess not only for this use case but for other users 😄

4. Having the possibility to disable some projects could also be cool.
   I don't know how familiar you are with conan toolchains but one idea could be this (completely invented code):

    # conanfile.py...

    def generate(self):
        deps = PremakeDeps(self)
        deps.generate()
        tc = PremakeToolchain(self)
        tc.projects["<project_name>"] = False  # or .disable = True or something like this, this is just a mockup
        # or
        tc.projects["<project_name>"].includedirs = [...]
        tc.projects["<project_name>"].cxxflags = [...]

Then, when a repo needs to be packed in a Conan recipe, we can have total control of what can we do, which projects/tests want to enable, which projects depend on which libs, etc.

Extra: it might be worth to consider making targetdir folder relative to location folder. This is related to how premake generates their makefiles. Could be interesting to generate all .make files in a build folder or something by default?

I'll stay tuned!
Thank you again 🐸

[nickclark2016]

For armv8 vs arm64, you can actually provide an alias on to Premake to map armv8 to arm64. It would look like:

premake.api.addAliases("architecture", {
  ["armv8"] = "arm64"
})

Hopefully this is useful for you in near future, before we can tackle other features required.

[perseoGI]

Hi @nickclark2016 I've been trying to create the alias as you told me but I don't think it is working... or maybe I've misunderstood it!

workspace "HelloWorld"
   configurations { "Debug", "Release" }
    
   premake.api.addAliases("architecture", {
     ["armv8"] = "arm64"
   })

project "HelloWorld"
   kind "ConsoleApp"
   language "C++"
   files { "**.h", "**.cpp" } 
   filter "configurations:Debug"
      defines { "DEBUG" }
      symbols "On"

   filter "configurations:Release"
      defines { "NDEBUG" }
      optimize "On"

Invoking premake as follows:

$ premake5 gmake --arch=armv8
Error: invalid value 'armv8' for option 'arch'

Am I doing something wrong? Thank you in advance!

[nickclark2016]

I'll have to check the code, but that alias may not be picked up on in the command line, which would be a deficiency if that is the case.

[Jarod42]

2.Automated Toolchain Integration (Similar to CMake)
CMake allows defining toolchains that load automatically before/after parsing the main CMakeLists.txt file without modifying the original build script.
This is a great feature because it lets users integrate Conan without altering existing CMake scripts. I’ve searched Premake’s documentation for a similar feature—something like a script injection capability—but couldn’t find anything.
The lack of such a feature forces us to patch upstream recipes that use Premake, requiring us to modify the premake5.lua file directly.

You might do an other way:
Having your premake script include the original premake script.
In addition, you might call function and overwrite lua function to your needs before to include the script.

3.Defining the Build Location Outside premake5.lua
Related to the previous point: Conan organizes folders (source_folder, build_folder, etc.), and it would be great if Premake allowed specifying the build location from the CLI or via script injection, without modifying premake5.lua.
Is there a way to achieve this in Premake? I couldn’t find one in the latest Premake 5 release.

There is newoption which allows to have new command line option,
then you might have objdir (_OPTIONS["objdir"] or "obj")

4.Configuring cppdialect Externally
In other Conan generators, Conan defines the C++ standard. However, with Premake, it seems we must modify premake5.lua manually to set cppdialect.
Again, a way to inject this information externally—without modifying premake5.lua—would be very beneficial.

Same as 3

5.Disabling Specific Projects in a Premake Workspace
Take a look at this project: yojimbo.
I don’t know if this project follows best practices for Premake, but I couldn’t find a way to disable specific test projects. In Conan Center Index, we do not compile upstream tests (as that is the responsibility of the upstream project).
Is there an official way to disable specific projects using Premake?

What do you mean by disabling projects exactly?
Would disabling a project disable dependent projects?

BTW, You can run make on the specific projects you want as make client server soak loopback;
make all will indeed also build test project.

[lolrobbe2]

@Jarod42 @nickclark2016 When it comes to a toolchain file does that mean something like KCONFIG? like with ESP-IDF?

where we generate an premakeConfig.h file and an premakeConfig.lua so one could do conditional compilation etc (ofcoarse this would be a module) where you could have a menuconfig action whete the action can change the sdkconfig.premake file itself

[perseoGI]

Greetings @nickclark2016 @Jarod42 @lolrobbe2

Sorry for the delay. I haven't had enough capacity to work on this until now.
I've made some progress on Conan's premake integration.

See the following links:

• Conan's draft PR improving premakes generator support: Premake generator: better integration conan-io/conan#17898
• Example C++ project consisting in a library package both tooled with premake (1 shared and 1 static library), and two library consumers. A CMake app and a Premake app: https://github.com/perseoGI/conan-premake-example

The main idea of a conan generator is to provide an interface for managing, calling, accessing the tool below.
A typical conan generator can be divided in three parts, in this case:

1. PremakeDeps: this class should be invoked from generate() method of a conan recipe and it should only be called if the project has any kind of external dependency. In the case, it will create specific lua files and tables per dependency (per configuration), see for example a conan_fmt_vars file:

#!lua

include "conanutils.premake5.lua"

t_conandeps = {}
t_conandeps["release_arm64"] = {}
t_conandeps["release_arm64"]["fmt"] = {}
t_conandeps["release_arm64"]["fmt"]["includedirs"] = {"/Users/perseo/.conan2/p/b/fmtf45352c521e23/p/include"}
t_conandeps["release_arm64"]["fmt"]["libdirs"] = {"/Users/perseo/.conan2/p/b/fmtf45352c521e23/p/lib"}
t_conandeps["release_arm64"]["fmt"]["bindirs"] = {"/Users/perseo/.conan2/p/b/fmtf45352c521e23/p/bin"}
t_conandeps["release_arm64"]["fmt"]["libs"] = {"fmt"}
t_conandeps["release_arm64"]["fmt"]["system_libs"] = {}
t_conandeps["release_arm64"]["fmt"]["defines"] = {}
t_conandeps["release_arm64"]["fmt"]["cxxflags"] = {}
t_conandeps["release_arm64"]["fmt"]["cflags"] = {}
t_conandeps["release_arm64"]["fmt"]["sharedlinkflags"] = {}
t_conandeps["release_arm64"]["fmt"]["exelinkflags"] = {}
t_conandeps["release_arm64"]["fmt"]["frameworks"] = {}

if conandeps == nil then conandeps = {} end
conan_premake_tmerge(conandeps, t_conandeps)

The cool part about conan is that this information, the dependencies information, are automatically generated by conan no matters which build tool where used in the dependency itself.

3. PremakeToolchain: this is the "new" part where we may have some chance to improve. A conan toolchain usually allows to interact with the build system scripts itself. Other build systems such as CMake, as told before, allows to create some files which will be executed before the main CMakeLists.txt. Following your instructions, I have managed to create a "similar workflow" by making conan create a custom conanfile.premake5.lua file which will invoke the upstream (original) premake5.lua file and our custom scripts, example:

#!lua
include("/Users/perseo/sources/conan-premake-example/consumer_premake/premake5.lua")
include("/Users/perseo/sources/conan-premake-example/consumer_premake/build-release/conan/conantoolchain.premake5.lua")

But a toolchain could and probably should be able to do more things.
In our case, I've added some capabilities to add some extra preprocessor variables:

    def generate(self):
        deps = PremakeDeps(self)
        deps.generate()
        tc = PremakeToolchain(self)
        tc.extra_defines["TEST"] = False
        tc.extra_cflags = ["-Werror"]
        tc.extra_cxxflags = ["-Wall", "-Wextra"]
        tc.extra_ldflags = ["-lm"]
        tc.generate()

This will update global workspace resulting a script with the following content:

include("conandeps.premake5.lua")   -- This will only appear if PremakeDeps is called

-- Redirect build objects and binaries to proper build folder (source folder in conan should never me modified to keep integrity)
local locationDir = "/Users/perseo/sources/conan-premake-example/consumer_premake/build-release"

workspace "*"
    cppdialect "gnu++17"   -- This will be automatically obtained from conan profile
    location(locationDir)
    targetdir(path.join(locationDir, "bin"))
    objdir(path.join(locationDir, "obj"))
    
    filter { "language:C" }
        buildoptions { "-Werror" }
    filter {}
    filter { "language:C++" }
        buildoptions { "-Wall","-Wextra" }
    filter {}
    linkoptions { "-lm" }

    defines { "TEST=0",  }

    conan_setup()

5. Premake: last but not least, from a conan recipe we can call Premake class which will actually call premake5:

    def build(self):
        premake = Premake(self)
        premake.configure()
        premake.build(workspace="App")

• configure() method will call premake this way:

RUN: premake5 --file=/Users/perseo/sources/conan-premake-example/consumer_premake/build-release/conanfile.premake5.lua gmake --arch=arm64

• build() method will make use of other conan generators depending on the OS (msbuild or make).

Questions

1. At the moment, the extra_defines functionality only works when creating a new define. I'm not being able to "unset" a define declared in upstream premake5.lua or to update its value -> how could achieve this? Is there a way of undefining a variable?

See log:

workspace "App"
   configurations { "Debug", "Release" }
   defines { "TEST=1" }  -- define in project

In file included from <built-in>:530:
<command line>:2:9: warning: 'TEST' macro redefined [-Wmacro-redefined]
    2 | #define TEST 1
      |         ^
<command line>:1:9: note: previous definition is here
    1 | #define TEST 0
      |         ^
1 warning generated.

And it will keep the value declared in the original premake5.lua file and won't be overwritten by toolchain file.

2. Related with the previous one, is there a way of overwritting values of the attributes of the workspaces/projects? E.g. to emulate building a project static or dynamic, CMake has the BUILD_SHARED_LIBS. It will be great to achieve this by overriding the values of kind "StaticLib" to kind "SharedLib", but as seen before, I'm not being able to overwrite existing values.

3. The same applies to fatalWarnings, there isn't a way of overwriting the value externally.

4. Is there a way of defining CFLAGS and CXXFLAGS independently? I tried to create a filter based on the language but didn't work.

5. This is also happening to us: architecture ignored on macOS #2136. Conan should allow cross compilation. I had temporary fix it by adding buildoptions and linkoptions with -arch <target architecture> but I guess this should be done my premake.

6. Is there a way of determining the .sln name of the project when using vsXXX action?

Thank you very much for your time and I hope this collaboration leads us to a good end!
Happy coding 🐸

[Jarod42]

1. At the moment, the extra_defines functionality only works when creating a new define. I'm not being able to "unset" a define declared in upstream premake5.lua or to update its value -> how could achieve this? Is there a way of undefining a variable?

undefines won't help, we pass the undefines (-U) after the defines (-D).
defines appends to the list, and compilers use the last one.
so defines('TEST=1') followed by defines('TEST=0') would result in TEST=0, but indeed clang has warning when redefining MACRO like that.

2. Related with the previous one, is there a way of overwritting values of the attributes of the workspaces/projects? E.g. to emulate building a project static or dynamic, CMake has the BUILD_SHARED_LIBS. It will be great to achieve this by overriding the values of kind "StaticLib" to kind "SharedLib", but as seen before, I'm not being able to overwrite existing values.

3. The same applies to fatalWarnings, there isn't a way of overwriting the value externally.

For API taking list (as defines) we append new values to the list.
for API taking single value, we overwrite value, so

project "app"
  kind "StaticLib"

-- ...

project "app"
  kind "SharedLib"

'app' would be a shared library and not a static library.
Note that, overwrite is done with identical scope/filter,
so if fatalwarnings are set a file scope (i.e filter "files:some_file" fatalwarnings "On"),
setting/overwritting it at project level won't impact that file.

4. Is there a way of defining CFLAGS and CXXFLAGS independently? I tried to create a filter based on the language but didn't work.

I don't think so

6 Is there a way of determining the .sln name of the project when using vsXXX action?

I think you want filename

Note that some prefix/postfix might be applied with some generators.

[perseoGI]

Thank you for your quick response!

Do you know the answers for 1) and 2) questions?

The filter part worked well!!! Thank you!

PERFILE_FLAGS_0 = $(ALL_CFLAGS) -Werror          # For c
PERFILE_FLAGS_0 = $(ALL_CXXFLAGS) -Wall -Wextra  # For cpp

Related with my last comment:

Is there a way of keeping absolute paths to on bindirs? I'm actually passing an absolute path but premake is converting them into relative paths to the project

[Jarod42]

1. Is there a way, without needing to know the project workspace name, to make * workspace overwrite any workspace?

There are way to iterate over projects.
Mostly used inside premake itself than for users.

Something along

for wks in premake.global.eachWorkspace() do
  for prj in premake.workspace.eachproject(wks) do
  -- ...
  end
end

2.I have another question, is it possible or valid to have multiple workspaces declared in a premake5.lua file? This will complicate things...

Never tried, but seems possible from above code.

[perseoGI]

Hmm thats a good one!
I'll try it, thanks a lot!

[perseoGI]

Hi mate, I've been testing as it seems a good idea.
Iterating over workspaces is working really good and I'm being able to modify all workspaces at once.
But the second loop is failing:

workspace "App"
   configurations { "Debug", "Release" }

project "main"
   kind "ConsoleApp"
   language "C++"
   cppdialect "C++17"
   files { "src/main.cpp", } 
  
for wks in premake.global.eachWorkspace() do
    for p in premake.workspace.eachproject(wks) do  -- this line is failing
     -- do something   
    end
end

Error: [string "src/base/workspace.lua"]:17: attempt to get length of a nil value (field 'configs')

Version: premake5 (Premake Build Script Generator) 5.0.0-beta6

Do you have any idea of how can I iterate over all projects on each workspace?
Thank you?

[perseoGI]

Hi team! @Jarod42 @nickclark2016,

I hope you’re doing well. I have one final question before we can release the Premake final integration/generator in Conan.

A key use case for this integration is the ability to programmatically update the project kind values. For instance, we need to be able to convert static libraries into shared libraries based on whether the Conan recipe has the shared option.

Could you please let me know how I can programmatically modify attributes for all projects?

Thank you very much for your support. I truly appreciate your time and effort.

Best regards!

[perseoGI]

I have another question, sorry for bothering you guys. This is for the sake of having a great integration with conan!

I'm encountering some problems with rpaths in macos.
This has been already reported in #2262
I can confirm it is still an issue

Consider this example:

ALL_LDFLAGS += $(LDFLAGS) -L../../../../.conan2/p/b/libs4c0faa52c961a/p/lib

In that folder, I have a static library and a dynamic library:

└── lib
    ├── libmath.a
    └── libutils.dylib

In macos, .dylib have to be linked with -Wl,-rpath,<path_to_lib>
Following this solution #2262 (comment) does not work as paths are relative to build folder.

1. Is there a way of keeping absolute paths to on bindirs? I'm actually passing an absolute path but premake is converting them into relative paths to the project.

2. Consider adding on macos machines:

ALL_LDFLAGS += $(LDFLAGS) -L/Users/perseo/.conan2/p/b/libs4c0faa52c961a/p/lib -Wl,-rpath,/Users/perseo/.conan2/p/b/libs4c0faa52c961a/p/lib

This works

[nickclark2016]

1. bindirs should remain relative.
2. rpath should be relative, not absolute. It is used for runtime lookup, and if it's absolute, generated binaries won't be portable.

[perseoGI]

Greetings again!

Is there a premake way of redefining a project in a workspace loop only if that project exists in the current workspace?

for wks in premake.global.eachWorkspace() do
    workspace(wks.name)
        location(locationDir)
        -- ... more configuration
        
        project "main"
            -- Only update this project if it exists in current wks
            defines { "TEST=0" }
end

I have tried several premake lua functions like this one https://github.com/premake/premake-core/blob/v5.0.0-beta6/src/base/workspace.lua#L168 (hasProject) but those don't work at the point of execution of the scripts.

Any idea?
Thank you in advance!

[perseoGI]

Greetings @nickclark2016 @Jarod42 any clue on this?
Thank you in advance!

[perseoGI]

And what about this one @Jarod42?
I'm stuck with this!

[perseoGI]

I have another question!
I'll like to modify externally the kind of libraries defined in a premake file like CMake BUILD_SHARED_LIBS.

How could I do this?
In conan, if a package is declared as a library we can pass an option called shared which could be True/False. If being true, in case of CMake or other build systems, it will end up forcing the value of all declared target libraries with SHARED.

[perseoGI]

Greetings, long time no see!

I've yet another question. I can see in the premake docs:

Premake generated makefiles do not (currently) support a make install step...

Are you working on this feature?
In CMake we have something like this kind of structure:

install(TARGETS pkg DESTINATION "."
        RUNTIME DESTINATION bin
        ARCHIVE DESTINATION lib
        LIBRARY DESTINATION lib
        )

By defining CMAKE_INSTALL_PREFIX you could externally customize the destination folder.
From conan perspective, it would be very nice if you finally implement something like a "built-in" install action, to be able to configure the install destination folder from an external parameter. It may be done by defining a "built-in" option called something like --prefix

What do you think @Jarod42 @nickclark2016?
Thank you in advance!

[Jarod42]

AFAIK, there are nothing in the pipeline for that.
Whereas it might be implementable for non-IDEs like makefile (ninja, ...),
I don't see a way for regular IDEs (visual studio, Codelite, XCode, ...).

[perseoGI]

So right now which is the best "standard" approach of installing a library or an executable with premake?
How could I tell premake to generate the corresponding Makefile code to allow installation in the system?

[Jarod42]

newaction?
Not ideal IMO (especially as it is unrelated to the generator used), but it might do the job.

[perseoGI]

Okay I understand,
Thank you for your time!