premake-users — Public discussion of the Premake build tool.

Re: [Premake-users] Patch for premake 4.4 beta 5 from premake 4

[Konstantin T. <an...@ya...>]

CC'ing premake developers.

24.06.2014, 18:09, "Vitaly Magerya" <vma...@gm...>:
>  TL;DR: could a brave ports comitter apply an update for
>  devel/premake4 at [1]? That would be much appreciated.
>
>  Redports logs for this update are at [2].
>
>  Note that redports for some reason doesn't invoke regression-test
>  target today; probably a bug on their part.
>
>  On 2014-06-24 09:51, Sergei G wrote:
>>   I had to update Premake 4 port (4.3) to 4.4 beta 5 on FreeBSD
>>   10.0-RELEASE #0.
>>
>>   I included patch file with changes applied to Premake 4 port. The
>>   changes consist of:
>>
>>   3 regression tests failed (it appears due to at least one missing patch
>>   file):
>  The main cause of these regressions is actually a very strange
>  one (and you're right that those patches are what fixed it in
>  the past). So, in one of it's routines premake tries to open
>  '/etc/ld.so.conf'; it does so via Lua function 'io.open'. Now,
>  FreeBSD doesn't have that file, and in theory 'io.open' should
>  return 'nil', which should cause premake to skip this file. What
>  actually happens is that 'io.open' returns some object that is
>  neither nil, nor a proper file object. Premake thinks that 'io.open'
>  succeeded, and tries to read from that non-nil, non-file object,
>  which doesn't work.
>
>  Why doesn't 'io.open' return 'nil' here is a mystery to me. Maybe
>  premake ships with buggy Lua sources. I don't know.
>
>  In any case, this problem is fixed in the patch at [1].
>>   Once I installed premake I observed that it generated Makefile with gcc
>>   in it, instead of clang. Should switch to clang be applied at premake or
>>   Box2D project level?
>  It appears that Premake only supports GCC for its "gmake" target.
>
>  It is possible to simply replace "gcc" with "clang" in the premake
>  sources, and it will mostly work, but:
>  1) it will not work for projects that use advanced options, since
>      clang does not support, and in fact fails on some of the flags
>      premake may pass to it ("-ffast-math" for example);
>  2) makefiles generated on FreeBSD will fail on other platforms
>      (not sure if premake promises them to work though).
>
>  The long-term solution for premake is to recognize "clang" as a
>  valid compiler, and provide a set of flags it understands.
>
>  The short-term solution for programs that use premake is to either
>  require GCC from ports, or to manually replace "gcc" with "clang"
>  before building, patching out incompatible compiler flags, if any.
>
>  Note that Box2D v2.3.1 doesn't seem to use any flags that clang
>  doesn't understand, so it is safe to change "gcc" into "cc", and
>  "g++" into "c++" in the makefiles that premake generates for it.
>
>  [1] http://tx97.net/~magv/diff/premake-4.4.b5.diff
>  [2] https://redports.org/buildarchive/20140624134401-54287/
>  _______________________________________________
>  fre...@fr... mailing list
>  http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>  To unsubscribe, send any mail to "fre...@fr..."

-- 
Regards, Konstantin

[Premake-users] Cat Street has added you on SkillPages

[Cat S. v. S. T. <no-...@sk...>]

<http://www.skillpages.com/i/ftuf/emailinvitelanding?user=0dba7009-698d-e211-9ad1
-a98fc6c611ca&signedParameters=wzb3ffZ1lVXks45qoc4lDL0B5ZSQzVWQn79iYnvyZYE.eyJlbW
FpbCI6InByZW1ha2UtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0IiwiZnJvbSI6IjBkYmE3MDA5LTY
5OGQtZTIxMS05YWQxLWE5OGZjNmM2MTFjYSIsInRvIjoiMzg0NWQxODAtODI5Mi01ZWYxLWJhYzItMjhl
MzAyYzI3YmUxIiwiaXNzdWVkX2F0IjoiMTM2MzM3NTY1NiIsInZlciI6IjEiLCJwIjoiMyJ9&emailMes
sageId=0419f413-698d-e211-af86-8e5ba9dd0dd1&emailType=Invite&sdate=201303151927&u
tm_source=EmailInvite&utm_medium=Email&emailLinkType=Logo>

Hi,

Become a part of your friend's network.

<http://www.skillpages.com/i/ftuf/emailinvitelanding?user=0dba7009-698d-e211-9ad1
-a98fc6c611ca&signedParameters=wzb3ffZ1lVXks45qoc4lDL0B5ZSQzVWQn79iYnvyZYE.eyJlbW
FpbCI6InByZW1ha2UtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0IiwiZnJvbSI6IjBkYmE3MDA5LTY
5OGQtZTIxMS05YWQxLWE5OGZjNmM2MTFjYSIsInRvIjoiMzg0NWQxODAtODI5Mi01ZWYxLWJhYzItMjhl
MzAyYzI3YmUxIiwiaXNzdWVkX2F0IjoiMTM2MzM3NTY1NiIsInZlciI6IjEiLCJwIjoiMyJ9&emailMes
sageId=0419f413-698d-e211-af86-8e5ba9dd0dd1&emailType=Invite&sdate=201303151927&u
tm_source=EmailInvite&utm_medium=Email&emailLinkType=ProfileThumb>

Cat Street
<http://www.skillpages.com/i/ftuf/emailinvitelanding?user=0dba7009-698d-e211-9ad1
-a98fc6c611ca&signedParameters=wzb3ffZ1lVXks45qoc4lDL0B5ZSQzVWQn79iYnvyZYE.eyJlbW
FpbCI6InByZW1ha2UtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0IiwiZnJvbSI6IjBkYmE3MDA5LTY
5OGQtZTIxMS05YWQxLWE5OGZjNmM2MTFjYSIsInRvIjoiMzg0NWQxODAtODI5Mi01ZWYxLWJhYzItMjhl
MzAyYzI3YmUxIiwiaXNzdWVkX2F0IjoiMTM2MzM3NTY1NiIsInZlciI6IjEiLCJwIjoiMyJ9&emailMes
sageId=0419f413-698d-e211-af86-8e5ba9dd0dd1&emailType=Invite&sdate=201303151927&u
tm_source=EmailInvite&utm_medium=Email&emailLinkType=ProfileName>

Invite sent: 15 March, 2013

Continue
<http://www.skillpages.com/i/ftuf/emailinvitelanding?user=0dba7009-698d-e211-9ad1
-a98fc6c611ca&signedParameters=wzb3ffZ1lVXks45qoc4lDL0B5ZSQzVWQn79iYnvyZYE.eyJlbW
FpbCI6InByZW1ha2UtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0IiwiZnJvbSI6IjBkYmE3MDA5LTY
5OGQtZTIxMS05YWQxLWE5OGZjNmM2MTFjYSIsInRvIjoiMzg0NWQxODAtODI5Mi01ZWYxLWJhYzItMjhl
MzAyYzI3YmUxIiwiaXNzdWVkX2F0IjoiMTM2MzM3NTY1NiIsInZlciI6IjEiLCJwIjoiMyJ9&cnId=0db
a7009-698d-e211-9ad1-a98fc6c611ca&emailMessageId=0419f413-698d-e211-af86-8e5ba9dd
0dd1&emailType=Invite&sdate=201303151927&utm_source=EmailInvite&utm_medium=Email&
emailLinkType=MainCallToAction>

pre...@li... was invited to join SkillPages by Cat
Street. To stop receiving emails from SkillPages click here
<http://www.skillpages.com/i/account/unsubscribe?signedParameters=wI66iDd5A3W0Nv3
36YkVjKXMUMZvbB1fU06RWyIVuvM.eyJlbWFpbCI6InByZW1ha2UtdXNlcnNAbGlzdHMuc291cmNlZm9y
Z2UubmV0IiwiaXNzdWVkX2F0IjoiMTM2MzM3NTY1NiIsInZlciI6IjEiLCJwIjoiMCJ9&emailMessage
Id=0419f413-698d-e211-af86-8e5ba9dd0dd1&emailType=Invite&sdate=201303151927&utm_s
ource=EmailInvite&utm_medium=Email&emailLinkType=Unsubscribe> .

© 2013 SkillPages, Blackrock Business Park, Dublin, Ireland and 228 Hamilton
Avenue, 3rd Floor, Palo Alto, CA 94301.

[Premake-users] Fwd: Схемы прибавить 86 % доходности

[Иволия <aga...@ra...>]

Схемы прибавить 71 % прибылли

;http://filuve.narod2.ru/sots-nalog-v-2011g.html 

Посмотрите по ссылке

В полном следовании действующему законодательству России 

[Premake-users] Win a signed copy of Programming in Lua 3rd Edition

[liam m. <lia...@go...>]

Hacker news thread if you would like to up vote it:
http://news.ycombinator.com/item?id=5192359

Lua-l mailing list thread: thread.gmane.org/gmane.comp.lang.lua.general/96963

Happy talking.

Re: [Premake-users] State of dependencies between projects

[Jason P. <st...@in...>]

That link more or less has it right. It is a planned 5.0 feature. @rgeary has something working in his own branch; there is no official implementation in Premake-dev at this time.


On Dec 27, 2012, at 6:32 PM, Anders Lindqvist <and...@gm...> wrote:

> Hi,
> 
> This is my first post and I'm very new to premake so please excuse me for my newbie question! I'm investigating it to see if premake would be a viable replacement to my own personal project generator. While I'm quite happy with it, it doesn't support as many platforms as it should and it could be a little more flexible as well.
> 
> I'm very C++-centric and currently mostly on Visual Studio 2010/2012.
> 
> The features that I have been unable to find in premake is related to more advanced dependencies between projects. Here is a list of the most useful features that I'm looking for:
> 
> a) If a project depends on another project ("links" in premake-terminology?), it will inherit all "public" include directories / defines / flags etc. This should be recursive, following dependencies.
> 
> b) Each project can define "private" include directories, defines, flags etc that is only applicable for that very project (not leaked).
> 
> c) If a project A make a "private" dependency to project B (think "links-private") it means that the cpp-files of A needs the headers of B, but anyone else depending on A will not need it. Example would be a library that fully encapsulates and hides the usage of libpng.
> 
> a) and b) are the most important ones.
> c) is mostly to make sure that you get compiler errors if you forget that you were supposed to encapsulate something.
> 
> This is probably something that quite a few people come across and hopefully you can point my to a solution. Unfortunately google hasn't been able to do so yet... I think that what I'm after is partially described here: http://industriousone.com/topic/specifying-usage-requirements-eg-include-dir-link-library but I've been unable to understand if it is exactly what I'm after, and what state it is currently in.
> 
> Cheers,
> Anders.
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712_______________________________________________
> Premake-users mailing list
> Pre...@li...
> https://lists.sourceforge.net/lists/listinfo/premake-users

[Premake-users] State of dependencies between projects

[Anders L. <and...@gm...>]

Hi,

This is my first post and I'm very new to premake so please excuse me for
my newbie question! I'm investigating it to see if premake would be a
viable replacement to my own personal project generator. While I'm quite
happy with it, it doesn't support as many platforms as it should and it
could be a little more flexible as well.

I'm very C++-centric and currently mostly on Visual Studio 2010/2012.

The features that I have been unable to find in premake is related to more
advanced dependencies between projects. Here is a list of the most useful
features that I'm looking for:

a) If a project depends on another project ("links" in
premake-terminology?), it will inherit all "public" include directories /
defines / flags etc. This should be recursive, following dependencies.

b) Each project can define "private" include directories, defines, flags
etc that is only applicable for that very project (not leaked).

c) If a project A make a "private" dependency to project B (think
"links-private") it means that the cpp-files of A needs the headers of B,
but anyone else depending on A will not need it. Example would be a library
that fully encapsulates and hides the usage of libpng.

a) and b) are the most important ones.
c) is mostly to make sure that you get compiler errors if you forget that
you were supposed to encapsulate something.

This is probably something that quite a few people come across and
hopefully you can point my to a solution. Unfortunately google hasn't been
able to do so yet... I think that what I'm after is partially described
here:
http://industriousone.com/topic/specifying-usage-requirements-eg-include-dir-link-librarybut
I've been unable to understand if it is exactly what I'm after, and
what state it is currently in.

Cheers,
Anders.

[Premake-users] G+ Premake community

[Branimir K. <bra...@gm...>]

Hi All,

I created G+ premake community for premake users in case anyone is
interested to join.
https://plus.google.com/u/0/communities/108711292675238179114

Branimir

[Premake-users] (no subject)

[Greg F. <gre...@ya...>]

http://catstudios3d.com/wp-includes/dgumvrpj.php
7/6/2012 8:00:06 AM

[Premake-users] Fwd: Custom Build Commands starting

[Konstantin T. <an...@ya...>]

18.03.2012, 01:20, "Jason McKesson" <ko...@gm...>:

>  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

Re: [Premake-users] Default project

[Konstantin T. <an...@ya...>]

21.03.2012, 00:54, "Jason McKesson" <jmc...@gm...>:
> Most IDEs have the concept of an "active" project. It's the one that is
> executed when you say "Debug". Premake has no way to designate that a
> particular project should be the initial "active" project. By default,
> the first project you create is the active one.
>
> Now personally, I don't care. It's a minor annoyance, having to switch
> active projects after creating them. However, I often get bugs like this
> one:
>
> https://bitbucket.org/alfonse/gltut/issue/72/problems-with-frameworkdlib
>
> This is from a user who's obviously not very familiar with their build
> tools. They've probably never seen a multi-project solution before, and
> so on. And since the first project I create is my "framework" project
> (it has to be for ease-of-use reasons), it is always the default
> "active" project. And since it's a static library, users can't execute it.
>
> Is it possible that we could add some setting to the solution that
> states which project is the default "active" project?

Feature request already exists:

http://sourceforge.net/tracker/?func=detail&aid=3463413&group_id=71616&atid=531881

-- 
Regards,
Konstantin

Re: [Premake-users] Default project

[liam m. <lia...@go...>]

On 20 March 2012 21:09, Jason Perkins <st...@in...> wrote:
> Anything is possible. You can submit a patch or file a feature request on the trackers: https://sourceforge.net/tracker/?group_id=71616
>
> -st.
>
> On Mar 20, 2012, at 4:54 PM, Jason McKesson wrote:
>
>> Most IDEs have the concept of an "active" project. It's the one that is
>> executed when you say "Debug". Premake has no way to designate that a
>> particular project should be the initial "active" project. By default,
>> the first project you create is the active one.
>>
>> Now personally, I don't care. It's a minor annoyance, having to switch
>> active projects after creating them. However, I often get bugs like this
>> one:
>>
>> https://bitbucket.org/alfonse/gltut/issue/72/problems-with-frameworkdlib
>>
>> This is from a user who's obviously not very familiar with their build
>> tools. They've probably never seen a multi-project solution before, and
>> so on. And since the first project I create is my "framework" project
>> (it has to be for ease-of-use reasons), it is always the default
>> "active" project. And since it's a static library, users can't execute it.
>>
>> Is it possible that we could add some setting to the solution that
>> states which project is the default "active" project?
>
>
> ------------------------------------------------------------------------------
> 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

If this is going to be cross platform then xcode3 will need some
changes, as every time you regenerate the project it leaves the old
files and therefore creates an new "executable" yet it is not the
active executable. Which is kind of annoying yet I have become used to
it :)

Liam

Re: [Premake-users] Default project

[Jason P. <st...@in...>]

Anything is possible. You can submit a patch or file a feature request on the trackers: https://sourceforge.net/tracker/?group_id=71616

-st.

On Mar 20, 2012, at 4:54 PM, Jason McKesson wrote:

> Most IDEs have the concept of an "active" project. It's the one that is 
> executed when you say "Debug". Premake has no way to designate that a 
> particular project should be the initial "active" project. By default, 
> the first project you create is the active one.
> 
> Now personally, I don't care. It's a minor annoyance, having to switch 
> active projects after creating them. However, I often get bugs like this 
> one:
> 
> https://bitbucket.org/alfonse/gltut/issue/72/problems-with-frameworkdlib
> 
> This is from a user who's obviously not very familiar with their build 
> tools. They've probably never seen a multi-project solution before, and 
> so on. And since the first project I create is my "framework" project 
> (it has to be for ease-of-use reasons), it is always the default 
> "active" project. And since it's a static library, users can't execute it.
> 
> Is it possible that we could add some setting to the solution that 
> states which project is the default "active" project?

[Premake-users] Default project

[Jason M. <jmc...@gm...>]

Most IDEs have the concept of an "active" project. It's the one that is 
executed when you say "Debug". Premake has no way to designate that a 
particular project should be the initial "active" project. By default, 
the first project you create is the active one.

Now personally, I don't care. It's a minor annoyance, having to switch 
active projects after creating them. However, I often get bugs like this 
one:

https://bitbucket.org/alfonse/gltut/issue/72/problems-with-frameworkdlib

This is from a user who's obviously not very familiar with their build 
tools. They've probably never seen a multi-project solution before, and 
so on. And since the first project I create is my "framework" project 
(it has to be for ease-of-use reasons), it is always the default 
"active" project. And since it's a static library, users can't execute it.

Is it possible that we could add some setting to the solution that 
states which project is the default "active" project?

[Premake-users] Custom Build Commands starting

[Konstantin T. <an...@ya...>]

16.03.2012, 16:31, "Jason Perkins" <st...@in...>:

>  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).

It would still be useful to have a "full" buildrule implementation at least for VS2008 for the first time (use of Qt with gmake is fully supported by my current implementation, but VS is not supported at all).


-- 
Regards,
Konstantin

Re: [Premake-users] Custom Build Commands starting

[Jason P. <st...@in...>]

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

Re: [Premake-users] Custom Build Commands starting

[Konstantin T. <an...@ya...>]

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

Re: [Premake-users] Custom Build Commands starting

[Konstantin T. <an...@ya...>]

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.

That's right.

> 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.

This tools can be auto-detected or configured by user.

> It's nice to have the functionality; don't get me wrong. But if they are
> the default case for you, then either Premake or Qt is doing something
> wrong.

Note that Qt is a cross-platform set of tools and libraries by design.

> If they're going to be the default, then what's the difference
> between Premake and a Lua file?

Look at project example [1]. Qt projects are as clean and simple as other Premake
projects.

[1] https://bitbucket.org/premake/premake-dev/wiki/Getting_started_with_Qt_and_Premake


-- 
Regards,
Konstantin

Re: [Premake-users] Custom Build Commands starting

[Konstantin T. <an...@ya...>]

15.03.2012, 23:54, "Jason McKesson" <ko...@gm...>:
> On 3/15/2012 3:48 AM, Konstantin Tokarev wrote:
>
>>  Also, I don't like explicit quoting like "%(file.fullpath)" in rules. I think quotes should be added automatically, i.e. file.fullpath and so on should contain quoted paths.
>
> If they contained quoted paths, what would happen if you need to modify
> the path? Like "%(file.pathname)/morepath/%(file.basename)" or something
> like that?

In bash multi-quoted paths like "path"/morepath/"otherpath" work fine, need to check cmd.exe though

-- 
Regards,
Konstantin

Re: [Premake-users] Custom Build Commands starting

[Jason M. <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.

It's nice to have the functionality; don't get me wrong. But if they are 
the default case for you, then either Premake or Qt is doing something 
wrong. If they're going to be the default, then what's the difference 
between Premake and a Lua file?

Re: [Premake-users] Custom Build Commands starting

[Jason M. <ko...@gm...>]

On 3/15/2012 3:48 AM, Konstantin Tokarev wrote:
> Also, I don't like explicit quoting like "%(file.fullpath)" in rules. I think quotes should be added automatically, i.e. file.fullpath and so on should contain quoted paths.
>
If they contained quoted paths, what would happen if you need to modify 
the path? Like "%(file.pathname)/morepath/%(file.basename)" or something 
like that?

Re: [Premake-users] Custom Build Commands starting

[Konstantin T. <an...@ya...>]

15.03.2012, 14:18, "Jason Perkins" <st...@in...>:
> On Mar 15, 2012, at 5:23 AM, Konstantin Tokarev wrote:
>
>>  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.
>
> Could you do me a favor and convert a few of your Qt build rules to this new syntax (or some variant of it), and post them to the build rules wiki page? It would be good to have those available as I work through the implementation.

https://bitbucket.org/premake/premake-dev/wiki/Qt_build_rules_draft

-- 
Regards,
Konstantin

Re: [Premake-users] Custom Build Commands starting

[Konstantin T. <an...@ya...>]

Also, I don't like explicit quoting like "%(file.fullpath)" in rules. I think quotes should be added automatically, i.e. file.fullpath and so on should contain quoted paths.

-- 
Regards,
Konstantin

Re: [Premake-users] Custom Build Commands starting

[Jason P. <st...@in...>]

Thanks!


On Mar 15, 2012, at 6:23 AM, Konstantin Tokarev wrote:
> 
> 15.03.2012, 14:18, "Jason Perkins" <st...@in...>:
>> Could you do me a favor and convert a few of your Qt build rules to this new syntax (or some variant of it), and post them to the build rules wiki page? It would be good to have those available as I work through the implementation.
> 
> I've planned to do so when you'll implement some base functionality, but I'm ready to do it ASAP.
> 
> You can see my old plans on 4 of them here (syntax is somewhat different):
> 
> https://gist.github.com/1350926
> 
> -- 
> Regards,
> Konstantin

Re: [Premake-users] Custom Build Commands starting

[Konstantin T. <an...@ya...>]

15.03.2012, 14:18, "Jason Perkins" <st...@in...>:
> On Mar 15, 2012, at 5:23 AM, Konstantin Tokarev wrote:
>
>>  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.
>
> Could you do me a favor and convert a few of your Qt build rules to this new syntax (or some variant of it), and post them to the build rules wiki page? It would be good to have those available as I work through the implementation.

I've planned to do so when you'll implement some base functionality, but I'm ready to do it ASAP.

You can see my old plans on 4 of them here (syntax is somewhat different):

https://gist.github.com/1350926

-- 
Regards,
Konstantin

Re: [Premake-users] Custom Build Commands starting

[Jason P. <st...@in...>]

On Mar 15, 2012, at 5:23 AM, Konstantin Tokarev wrote:
> 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. 

Could you do me a favor and convert a few of your Qt build rules to this new syntax (or some variant of it), and post them to the build rules wiki page? It would be good to have those available as I work through the implementation.


>> The way you've described it, the system has to detect that
>> "rule.compiler" accesses some context data, while "if not
>> rule.flags.DebugInfo then return "-s" end" is a Lua chunk with its own
>> return statement. This requires that Premake actually *parse* the text
>> within the %() segment to figure out if it's just accessing context data
>> (something that you can prepend "return context." to and get a valid Lua
>> chunk) or an actual Lua chunk to be executed.
> 
> I think it will always load chunk. Jason: could you clarify this?

Jason McKesson is right here, there would need to be some differentiation, otherwise you would always have to write $(return cfg.objdir) instead of $(cfg.objdir). 

-st.