From: Konstantin Tokarev <annulen@ya...> - 2012-03-21 09:38:35
18.03.2012, 01:20, "Jason McKesson" <korval2@...>:
> On 3/16/2012 5:03 AM, Konstantin Tokarev wrote:
>> You may also forget about any GUI. There's no GUI toolkit in the world which is both
>> cross-platform and is not "external" from IDE's point of view (well, in Qt Creator you
>> can usually assume that you have at least one installation of Qt shipped within IDE
>> or auto-detected, but that's an exceptional case and QtC is not directly supported
>> by Premake).
> There is a big difference between having a `Win32` configuration that
> adds a couple of .libs for Win32 usage, and having reams of special
> build rules that force the users to have various other tools in specific
> places just to compile something. Unless you're talking about building
> layout files for GUI systems, the most you have to do is just specify
> some libraries.
Well, there may be different use cases. But no build rule force user to have a tool unless
it's used it the project; you are even not forced to use plugins providing
these rules ;)
Those libraries come with the system; if they don't have
> them, then that means the system is likely broken.
> Things like Qt are third party libraries and thus must be located.
Practically nobody uses Qt without its code generation tools.
>> Forget about cross-compilation toolchains for generic Linux devices. They all have
>> custom placement of compilation tools and custom naming of them.
>> Forget about compiled languages like D, Fortran, OCaml, Haskell, etc. They are not
>> part of "native" platform development environments.
> Supporting other languages means supporting *other* languages. This
> should be first-class support provided by Premake, just as it provides
> support for C/C++/C#. It should not be a batch of ad-hoc build rules.
I tend to disagree. Custom rules seem to be effective and easy way to provide
support for new languages.
> That way, we can do things like prevent the user from doing things that
> don't make sense, like trying to make Visual Studio build and link D
> projects and such.
Why should we do that? VS cannot compile D out of the box, but with our
custom rule it can. That's great, isn't it?
> Otherwise, you're just turning Premake into a generic platform for
> executing platform-specific command-lines, like CMake, or for that
> matter, Make itself.
CMake is broken from top to bottom (yes, I worked with its code too).
It tries to be autotools with C++ instead of shell scripts and m4 instead of being
something more high-level and IDE-friendly.
I know a lot of people which would use Premake as CMake replacement if it had
> I don't like the idea of Premake becoming CMake with Lua. That sounds
> suspiciously like telling me how to layout my projects, forcing me to
> use environment variables so it knows where stuff is.
Nobody proposed it. You will always be able to use Premake the same way
as you do now.