Re: [Premake-users] Custom Build Commands starting
On GitHub now!
Brought to you by:
starkos,
ttk-bandit
From: Jason P. <st...@in...> - 2012-03-16 12:32:26
|
I think you two are in violent agreement, and rapidly getting into philosophical territory. It is my intention to fully support the Qt use cases, and to maintain Premake's simple style and syntax in the process. Really basic build rule support is now in premake-dev. Visual Studio 2008 only (I am hoping to add VS 2010 today), C/C++ only. No token replacement so you'll have to rely on Visual Studio's built-in tokens (i.e. $(InputName), etc.). Only supports commands and outputs, and both must be specified as tables. configuration "**.xyz" buildrule { commands = { "xyc -c $(InputFile) -o ($IntDir)$(InputName).obj" }, outputs = { "$(IntDir)$(InputName).obj" } } This meets the needs of my current project, so it might stay like this for a bit while I move the Gmake action over to the new APIs (including build rules). On Mar 16, 2012, at 8:03 AM, Konstantin Tokarev wrote: > > > 16.03.2012, 04:29, "Jason McKesson" <ko...@gm...>: >> On 3/15/2012 2:23 AM, Konstantin Tokarev wrote: >> >>> 15.03.2012, 09:11, "Jason McKesson"<ko...@gm...>: >>>> It's a *build system*, not an application; it's not that complicated. >>>> And if your build system is so big and complex that you can lose track >>>> of what globals, add-ons, and so forth you've included, something has >>>> gone wrong somewhere. >>> Premake is an application, and it's already complex. Add-ons are supposed >>> to extend *Premake* out-of-the-box capabilities and may be written by >>> 3rd parties. >>>> Remember: build rules are supposed to be the exception, not the default. >>> For my use cases they will be default (e.g., Qt support requires at least 6 build >>> rules). Also remember that build rules can be used to implement support for >>> programming languages other than C/C++, code generators, and preprocessors. >> >> Premake is, generally speaking, for being able to have a cross-platform >> build system that works the same everywhere. That way, I can develop >> using Visual Studio, but you could use Make, and someone else can use >> Code::Blocks, etc. And the source of the build is a single, simple format. >> >> Build rules basically throw away any hope of platform neutrality. You're >> effectively *relying* on certain things not only existing on the user's >> machine, but them being in certain places (even if it's just the search >> path). Build rules are always platform-specific. In some cases, they can >> be build-tool-specific. > > Than, generally speaking, you cannot use Premake for any cross-platform development > which is not limited to simple console C/C++ applications. If you use 3rd party libraries > which are not integrated with your development environment (e.g., Visual Studio), you > cannot be platform-neutral. But cross-platform libraries are usually not a part of any > platform-specific development environment. > > 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). > > 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. > > Sad but true. > > I think that your requirement of "platform neutrality" limits possible use cases of Premake > too much. You may have other opinion though. > > -- > 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 > Pre...@li... > https://lists.sourceforge.net/lists/listinfo/premake-users |