18.03.2012, 01:20, "Jason McKesson" <korv...@gmail.com>: > 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 enough features. > 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. -- Regards, Konstantin ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Premake-users mailing list Premake-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/premake-users
