Further premake improvement - defining action as it's own function...

[Tarmo Pikaro]

Hi !

Currently premake has a command line argument, which basically determines for which platform to generate project file:

 codelite          Generate CodeLite project files

 gmake             Generate GNU makefiles for POSIX, MinGW, and Cygwin

 vs2005            Generate Visual Studio 2005 project files

 vs2008            Generate Visual Studio 2008 project files

 vs2010            Generate Visual Studio 2010 project files

 vs2012            Generate Visual Studio 2012 project files

 vs2013            Generate Visual Studio 2013 project files

 vs2015            Generate Visual Studio 2015 project files

 vs2017            Generate Visual Studio 2017 project files

 xcode4            Generate Apple Xcode 4 project files

I would prefer to have it as a built in function. So basically if developer needs to have same project ported to vs2010, vs2012, vs2013 (For example with Autocad platforms, which require specific visual studio) - 

it would be possible to configure multiple projects using same keyword. 

Currently good term "platform" is already reserved for specifying cpu architecture - like "Win32", "x64" - so one approach could be rename "platforms" to "cpus" - but in Visual studio platform is named as a platform

- so may be this is not best option.

May be some sort of "apibase <vs2010|vs2012|android|...>" or "sdkbase <...>".

Besides listing supported api bases - it should be possible to specify for example android specific compilation, and one approach is to add new specific keyword for supporting operation like this, another approach is extend

"filter" - for example "filter { "apibase:vs2010", "Debug", "platforms:Win32" }

Even through for my own tool ( https://groups.google.com/forum/#!topic/premake-development/HLNboJpKy20 ) - I can proceed with whatever approach, I would prefer to walk in hand by hand with premake, because premake has wider

support community unlike syncProj.

Does my proposal sounds like anything doable ?

[Tarmo Pikaro]

So basically I haven't finished my idea...  new keyword versus extending "filter" - I would propose to extend "filter".

One downside is that "filter" (as the rest of implementation) goes into more complex direction.

[starkos]

Premake has the ability to trigger an action programmatically using `premake.action.call()`. But to ensure that things generate correctly you really should re-run the baking pass in between each call too.

I'm not sure I follow the rest of your proposal. It would be pretty easy to register a new action called "all" or something which would then call all of the actions you wanted to run. Is that what you're looking for?

[Tarmo Pikaro]

Basically what I want is to have it written down like this:

apibase|os|sdkbase { "vs2015", "android" }

-- apibase / os / sdkbase - is something to decide.

project "AndroidWindowsProject"

    location "."

    configurations {  "Debug","Release" }

    platforms { "ARM","ARM64","x64","x86" }

    uuid "0bfed5fa-f75a-457d-bd35-1d78ef56bd34"

    kind "SharedLib"

    files { "PortLayerBase.cpp" }

    filter { "apibase:android" }

        files { "AndroidPortLayer.cpp" }

    filter { "apibase:vs2015" }

        files { "WindowsPortLayer.cpp" }

And this would dump me Windows project (Named for example AndroidWindowsProject_vs2015.vcxproj) for Visual studio 2015, and Android project  (Named for example AndroidWindowsProject_android.vcxproj) 

In theory I can list all visual studio projects, "vs2010", "vs2015", and premake5 would dump all variations of visual studio solutions / projects.

[starkos]

It is possible that I'm not understanding something completely, but based on what I *do* understand, I don't think this is an approach that Premake should take.

If we can get multiple actions working cleanly, we could certain extend `premake.action.call()` to take a list of actions instead of just one, and extend the command line logic to allow multiple actions to be specified. But I would not expect to provide a project API like you describe to "hardcode" a set of outputs.

That's my $0.02 anyway; I'll leave the floor open for others to discuss.

[Tarmo Pikaro]

> If we can get multiple actions working cleanly, we could certain extend `premake.action.call()` to take a list of actions instead of just one, and extend the command line logic to allow multiple actions to be specified. 

Can you elaborate bit deeper - how do you see this feature to be implemented ?

So basically my assumption is that I want to call multiple different actions at once, I prefer not to use function (I have used in some project already).

> But I would not expect to provide a project API like you describe to "hardcode" a set of outputs.

I don't see it like this. Basically whenever you're coding - you are testing against some particular platform - you normally cannot say - this will work on any cpu architecture on any machine on any os.

Basically now you variate visual studio version (for windows) - which could refer to some particular windows version (it's not explicit - but somehow like this).

I by myself see that 32 bit and 64 bit coding is almost the same, may be except you're handling call stacks ( https://sourceforge.net/p/diagnostic/svn/HEAD/tree/src/ResolveStack.cpp#l53 )

so variation could happen easily in 32 <> 64 bit - but cpu architecture is not given from command line ?!

Basically I think it would be easier to specify all platforms which premake support within .lua script rather than put it into .bat / build script and then search where is that one coded.

One question is also if you omit "apibase vs2015 | ... " - then premake could create support for all platforms it knows.

> That's my $0.02 anyway; I'll leave the floor open for others to discuss.

Hey premake developers - your opinion on this one ?

[Sam Surtees]

If I understand correctly, you want this:

premake5.exe vs2015 vs2017

Instead of:

premake5.exe vs2015
premake5.exe vs2017

Is this correct?

[Tarmo Pikaro]

Actually so far I had only one project which were cross visual studio ( but not cross platform, this is my next step). But so far I have written multi vs solution as following:

function ModelerProject( AutocadMajorVersion )

    --  .arx can be compiled only against Visual Studio version which it supports.

    if AutocadMajorVersion == 18 and ( buildvsver ~= "vs2008" ) then

        return

    end

    if AutocadMajorVersion == 19 and ( buildvsver ~= "vs2010" ) then

        return

    end

    if AutocadMajorVersion == 20 and ( buildvsver ~= "vs2012" ) then

        return

    end

    if AutocadMajorVersion == 21 and ( buildvsver ~= "vs2015" ) then

        return

    end

    solution ("vm-modeler" .. AutocadMajorVersion .. "_" .. buildvsver)

        platforms {  "x32", "x64" }

        configurations { "Debug", "Release" }

        objdir (  "obj/" .. "R" .. AutocadMajorVersion .. "_" .. buildvsver)

    project ("vm-modeler" .. AutocadMajorVersion .. "_" .. buildvsver)

...

        if AutocadMajorVersion == 21 then

            acadVersion = "2017"

        elseif AutocadMajorVersion == 20 then

            acadVersion = "2015"

        elseif AutocadMajorVersion == 19 then

            acadVersion = "2013"

        elseif AutocadMajorVersion == 18 then

            acadVersion = "2011"

        end

        includedirs { 

            "\\libraries\\ObjectARX" .. acadVersion .. "\\utils\\brep\\inc", 

            "\\libraries\\ObjectARX" .. acadVersion .. "\\inc-x64", 

            "\\libraries\\ObjectARX" .. acadVersion .. "\\inc", 

        }

...

end  --function ModelerProject

    ModelerProject(18)

    ModelerProject(19)

    ModelerProject(20)

    ModelerProject(21)

And then I required to run premake with all vs studio version, like you've mentioned.

But come to think more about it - I need to vary project name and potentially solution name according to platform / solution - so it makes more sense to make this variation into script itself.

So filter would simplify the syntax over if-else kind of scanning - but I'll check now how easy to have built-in support in syncProj.

[Tarmo Pikaro]

Btw - there is still one problem with visual studio / os selection.

Currently one of use cases I want also to tackle is to be able to generate solution for vs2015, but project for vs2010/2/3 - so some sort of mixture. One .lua however typically should specify either solution or project configuration.

solution.lua (for vs2015)

   project1.lua (for vs2012)

   project2.lua (for vs2015)

To be able to build this kind of system - you need to run premake 2 times, and generate solution for vs2015 first, and then to generate project1 for vs2012. And when you're generating project1 - you need also to generate some intermediate solution for project1. 

I would prefer not to generate what I don't want. (In this case solution for vs2012).

If we would have built-in support in premake - you would need only one run-round.

[Tarmo Pikaro]

I've decided to call "action" as "osbase". It will be project specific keyword (potentionally optional), and will define to which visual studio version to build.

Initial ideas about how this function call will look like in Project class:

/// <summary>

/// Tags platform

/// </summary>

public enum EKeyword

{

    /// <summary>

    /// Typically set for Android packaging project.

    /// </summary>

    None = 0,

    /// <summary>

    /// Windows project (32 or 64 bit)

    /// </summary>

    Win32Proj,

    /// <summary>

    /// Android project

    /// </summary>

    Android

}

... class Project:
...

    /// <summary>

    /// "4.0" for vs2010/vs2012, "12.0" for vs2013, "14.0" for vs2015

    /// </summary>

    public String ToolsVersion;

    public EKeyword Keyword;

    public String getOsBase()

    {

        switch (Keyword)

        {

            case EKeyword.Android:

                return "android";

            case EKeyword.None:

                return "package";

            default:

            case EKeyword.Win32Proj:

                if (Double.Parse(ToolsVersion) <= 4.0)

                    return "vs2012";

                return "vs2015";

        }

    } //getOsBase

    /// <summary>

    /// Sets os base, returns false if not supported.

    /// </summary>

    public bool setOsBase(String osBase)

    {

        switch (osBase.ToLower())

        {

            case "package":

                ToolsVersion = "14.0";

                Keyword = EKeyword.None;

                break;

            case "vs2010":

            case "vs2012":

                ToolsVersion = "4.0";

                Keyword = EKeyword.Win32Proj;

                break;

            case "vs2013":

                ToolsVersion = "12.0";

                Keyword = EKeyword.Win32Proj;

                break;

            case "vs2015":

                ToolsVersion = "14.0";

                Keyword = EKeyword.Win32Proj;

                break;

            case "android":

                Keyword = EKeyword.Android;

                break;

            default:

                return false;

        }

        return true;

    } //setOsBase

By doing so syncProj will not require special command line argument, only filename. premake picks up file using --file=<file> command line, syncProj will accept only script filename (.cs), nothing else.

filter:ing by platform name will not be supported, but it's also easy thing to do in c# / lua.

[Tarmo Pikaro]

And demo .cs will look like this:

    project("test_Android1.NativeActivity");

        osbase("android");

        configurations(  "Debug","Release" );

        platforms( "ARM","ARM64","x64","x86" );

        uuid("a5651b81-1c70-4416-b60f-a5b2094a211a");

        kind("SharedLib");

        toolset("Clang_3_8");

[Tarmo Pikaro]

osbase is not good term anyway...  something like "ide" or "sdkbase", "target" or "os" came to my mind, but none of them seems to be good.

[Tom van Dijck]

Just in general I think this is not really an idea I'm very excited about, premake is supposed to be a tool to configure projects once, and use it on many different platforms.. for example something as simple as:

```
solution "foo"
project "bar"
kind "staticlib"
files { "**.cpp", "**.h"}
```

is a premake project that works across all IDE's, all platforms, and all OS's, and I for sure like to keep it that way...
introducing a keyword that ties a project to a particular OS or IDE seems completely counter to the idea of premake.

Allowing premake to run multiple actions, as Sam said, sounds like an awesome idea... I would completely support that.... but introducing a keyword to restrict a project to just be for one platform/IDE/os would not be a good idea...

besides that however, you can already achieve it through the following simple code:

```
if _ACTION == "vs2015" then
     project "vs2015_project"
         dostuffhere()
end
```


All this said, several people have asked what it is you are trying to accomplish, and I'll just add myself to the list of people who are curious... What is it you want to achieve? maybe there is other ways to get that result without modifying premake, introducing extra keywords, or maybe we're simply misunderstanding what you are trying to do...

[Tarmo Pikaro]

Like I said in previous post - I want to variate different visual studio's and may be also different build targets - 

Same thing is applicable for android versus windows - I want to have one solution, but two different build targets - one for windows, one for android. (With a different deployment options)

 

Previously I have done something like this for Autocad - vs2010, vs2012, vs2015 variation. But I needed to run premake in multiple runs, which is not nice.

But I think it makes sense to have project specific keyword ("osbase") for configuring project / solution, since project and solution are visual studio version specific.

[Sam Surtees]

If you want to target multiple versions of VS within the same solution, you can use the toolset API. This avoids the multiple runs of Premake.

As for having a project for Windows and a project for Android, it's already possible to do this, use the system API.