Opened 12 years ago
Closed 4 years ago
#1518 closed task (wontfix)
Submit premake modifications to upstream
Reported by: | leper | Owned by: | Itms |
---|---|---|---|
Priority: | Nice to Have | Milestone: | |
Component: | Build & Packages | Keywords: | |
Cc: | Yves, fabio | Patch: |
Description (last modified by )
We bundle a modified version of premake 4.3 to create our workspaces (VS projects, makefiles, ...).
Some of our modifications are bug fixes (relative paths, precompiled headers), enhancements (cxxtest support, nasm support) or extensions to upstream features (os_getversion support for POSIX sytems (os_getversion is a backport from premake-4.4-beta4)).
It would be nice to
- submit these modifications to upstream by adding a pull request there. See the premake contribution guidelines for information on how to submit patches.
- add diff/patch files and a readme describing the use of the modification to the premake dir (analogous to how we handle nvtt modifications). (could be useful for the first task)
The attached file is a diff against the imported premake version (see link above) before r11970.
Attachments (1)
Change History (18)
by , 12 years ago
Attachment: | 0ad_premake.diff added |
---|
comment:1 by , 12 years ago
Cc: | added |
---|
comment:2 by , 11 years ago
I added a pull request with our additions to getversion() upstream https://bitbucket.org/premake/premake-dev/pull-request/25/add-unix-support-to-osgetversion.
comment:3 by , 11 years ago
Cc: | added |
---|
comment:4 by , 11 years ago
The pull request hasn't been merged, but a slightly modified version of it has been committed to premake-dev and premake-stable (which will become 4.4).
We still need to adjust our local version to be the same as the code upstream, but that shouldn't be hard to do.
comment:5 by , 11 years ago
Ideally there should be also a configure option for using system premake, similar to nvtt/mozjs/enet.
comment:6 by , 11 years ago
Description: | modified (diff) |
---|
This is sort of the reason for this ticket (and to keep us from having to maintain a fork), but we depend on some of the modifications and I don't know (for all of them) wether they are still used/needed or if they should just be dropped. (I added Yves to cc some time ago as he did most of those changes afaik)
Also premake-dev (which will become 5.0) changes a lot of the api so we will probably have to do some work once that is released (or hits beta).
And just that I mentioned it here #1516 should probably be fixed properly and submitted too..
comment:9 by , 11 years ago
r13512 imports upstream pull request #7 and modifies it a bit to handle case of a missing /etc/ld.so.conf gracefully (happens on BSDs). Also imports os.is64bit(), but strips the native code implementation, as that only works on windows currently and isn't needed at the moment.
comment:13 by , 8 years ago
Premake5 is actively being developed, and they are not likely to keep maintaining the 4.x branch much longer. I created a new ticket for the migration: #3729.
On top of that, they migrated to GitHub so most of the links here are broken.
Leaving this ticket open sounds sensible because the list of customizations is useful, but basically we should focus on a migration more than on 4.x IMO.
comment:14 by , 8 years ago
In light of that, we should probably just apply the patch from #404, since we no longer want to stay as close to 4.x upstream as possible. Wdyt?
comment:15 by , 6 years ago
Description: | modified (diff) |
---|---|
Milestone: | Backlog → Work In Progress |
Owner: | set to |
This should be closed as wontfix since we now use premake5 by default (#3729) and will drop premake4 completely soon.
However, since this ticket is tracked by the package maintainers who want to unbundle premake, I would like to submit a patch adding option --with-system-premake5
to update-workspaces.sh
, before closing it.
comment:17 by , 4 years ago
Milestone: | Work In Progress |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
CCing Yves as he did most of the changes to premake.