Closed Szeptyk closed 10 years ago
I have added a new premake5 based script, since premake5 has better support for varying configurations thereby allowing us to add debug/release for visual studio solutions but retain a single build configuration elsewhere (since we used stripped symbol files instead).
To use this script you must be running a dev version of premake5, available at http://sourceforge.net/projects/premake/files/Premake/nightlies/ Another advantage of using the latest premake is that it supports vs2013 as an action, thereby avoiding the necessity to upgrade the project when loading into VS.
The MSVC debug release will generate libraries with a "d" suffix. A premake5 build option is now also available for libemergent.
Not sure what you mean by having to manually set the paths manually since the appropriate paths for include and libs are already configured in the premake script, all are relative to the build directory. The links should actually have no effect on the VS configuration since it is building a static library. However, the links to libemergent, libusb-1.0, freeimage and libpsinc will be required in a project that uses libpsinc.
Hi, Thank you for premake5, unfortunately we cannot use it since it is in the dev. state. Can I ask you to add more configurations to the premake4 as well, debug release, x32, x64. The same way as you did for premake5. Also it is missing the includedirs { .....} from the other dependencies (libemergent, freeImage) which need to be set manually in the vs project every time we run the premake.
Hi guys, I have prepared an example lua, please consider putting those changes in. The VS project compiles nicely and all of the configurations are split into different folders.
solution "psinc" language "C++" targetdir "lib" includedirs "include" libdirs "lib" excludes { ".bak", "~" }
configuration "vs*"
configurations { "debug", "release" }
platforms { "x32", "x64" }
configuration "not vs*"
platforms "native"
configuration { "vs*", "debug", "x32" }
targetdir "lib/Debug_32"
configuration { "vs*", "release", "x32" }
targetdir "lib/Release_32"
configuration { "vs*", "debug", "x64" }
targetdir "lib/Debug_64"
configuration { "vs*", "release", "x64" }
targetdir "lib/Release_64"
project "libpsinc"
kind "SharedLib"
targetname "psinc"
links { "emergent", "usb-1.0" }
files { "include/psinc/**h", "src/psinc/**.cpp" }
configuration "linux"
postbuildcommands "./strip lib/libpsinc.so"
configuration "not vs*"
flags "Symbols"
buildoptions { "-Wall", "-Wno-sign-compare", "-std=c++11", "-O3", "-D_FORTIFY_SOURCE=2" }
linkoptions { "-Wl,-soname,libpsinc.so.0" }
configuration "vs*"
defines { "NOMINMAX" }
kind "StaticLib"
includedirs { "../../libemergent/include", "../../FreeImage/Source", "../../../libusb-1.0.19/include" }
configuration "debug"
flags "Symbols"
targetname "psincd"
configuration "release"
flags "Optimize"
I was actually working on some changes (which are now pushed) when you posted this. I have included the fix for the NOMINMAX issue. The targetname for VS is now based on the platform and configuration (for example it will generate psinc_debug_x32.lib).
The above changes were to the premake5 file, we won't be changing the premake4 one as the lack of per-project configurations would affect our internal production builds until we can make the switch to v5 (at which point the premake4 script will be deprecated). Matching changes have been included in the libemergent build script too.
The includedirs you specify are outside the scope of the psinc directory and since there are no guarantees as to how a developer will structure their folders or even that the folders will be the same name we will not be adding those. The documentation specifies copying the relevant include files to the include folder of libpsinc (on a linux system we simply symlink them to /usr/local/include so they are discoverable anywhere, but unfortunately Windows does not have the same conventions). If you are setting up a build process, for continuous integration perhaps, then it would be straightforward enough to create you own script for copying the headers across.
As an addendum, there's no reason not to use premake5; it's not going to produce anything that you deploy, simply the project files. It won't introduce stability issues to anything you build after using it.
Copying the header files under windows is not a good idea, it messes up the project (think about the maintenance and updates). Regarding the directory structure (and includes), you can specify one in order to build the project correctly under windows. Or add the include paths as a parameter to the build script. Using a development version of the premake is not a good idea since it has not been fully released/tested.
Is the change that I have suggested in premake4 going to affect your linux build?
You're at liberty to maintain your own script. We shan't be implementing any of these unnecessary changes for the reasons outlined above.
One thing you might want to take a look at is the command mklink
which creates symbolic links under NTFS. You should be able to symlink the libemergent/include/emergent
directory into the include directory of libpsinc. Whenever libemergent is updated, libpsinc will be automatically using the latest headers. The same can also be performed with the other headers and the static libs themselves.
Example:
> cd C:\Users\dan\Documents\libpsinc\cpp\include
> mklink /D emergent ..\..\..\libemergent\include\emergent
Hi Guys, nice lib, only VS is not fully supported in the premake file. Is it possible for you to add more configurations: Debug, Release x32, x64 as well as paths in libdirs, includedirs, links, etc. to the other dependencies? Every time I re-run premake I need to set all of the references/paths manually which is not ideal. For example:
configurations { "Debug", "Release"} platforms { "x32", "x64" } ... configuration { "windows", "vs*", "x32" } targetdir { } includedirs { .....}
Thank You in Advance. If you need any help/info just let me know.