Re: Build Script in D
On Saturday, 19 January 2013 at 15:32:46 UTC, David wrote: I compile pre-compile glfw for windows, but on Linux/OSX etc. I have it as submodule and it works fine! :) works for me too, but this is sad that i need to use 3rd party libs just to create render window and handling input(well, it's possible to create cocoa window using plain c, but that would require some time which i don't have right now) :(
Re: Build Script in D
Am 18.01.2013 09:13, schrieb evilrat: On Sunday, 13 January 2013 at 10:47:41 UTC, David wrote: Seems like I have ran into the 1% with all of the C projects I use. cause my pc dead i'm now also forced to use glfw on osx(cause x11-d wrapper works on linux only), now i know why you are felt to that 1%, you are trying to use unstable versions of libs which is under middle of development process. unless dev team has fully automated snapshot building system you are out of luck to get precompiled binaries of actual version O_- I compile pre-compile glfw for windows, but on Linux/OSX etc. I have it as submodule and it works fine! :)
Re: Build Script in D
for anything outside D there is enough makefiles, autotools, cmake, whatever. also there is OS package system which for sure contaion most of these libraries, for me it's enough to not bother about building own C build system Using make with D works great, also there is cmake for D. But try to use two tools (d buildscript and let's say cmake) on windows. You have to force the user to either install mingw/cygwin or cmake/make and VS (cmake can only generate for mingw-make and VS not dmc). Users will end up not using it. stb_image e.g. is in no OS-Package (which also don't exist for windows)
Re: Build Script in D
On Saturday, 12 January 2013 at 16:34:12 UTC, David wrote: Using make with D works great, also there is cmake for D. But try to use two tools (d buildscript and let's say cmake) on windows. You have to force the user to either install mingw/cygwin or cmake/make and VS (cmake can only generate for mingw-make and VS not dmc). Users will end up not using it. stb_image e.g. is in no OS-Package (which also don't exist for windows) of course makefiles work, it's just hated by so many programmers... for windows there is 99% chance that already compiled executables/libraries exists. and if some project doesn't have binaries for windows, it's maintainers fault, not windows. just imagine yourself compiling for example Qt or chrome on single core 2Ghz machine with 1gb ram because there is no compiled binaries, would you be happy after that? but... we already going to OT, i don't want to start holy wars about build systems.
Re: Build Script in D
A class like this in Phobos would make it a lot easier for newcomers. :-)
Re: Build Script in D
also something like this for custom target: auto builder = Builder( homepath!./, arch!x86, mode!debug ) Doesn't work, these are compiler flags, which differ from compiler to compiler. You could make the builder call the compiler to set the flag, but I would move that directly to the compiler. // assuming all methods returns ref to self so it could be just simple calls builder.addSrcPath(path_to_src_folder_1); // or can be chained builder.addSrcPath(path_to_src_folder_2). addSrcPath(path_to_src_folder3); And how does chaining help? That makes everything just uglier. builder.addImportPath(path_to_imports); builder.addLinkLib(somelib.a); Need to be set for the compiler, A C compiler doesn't need the flags of a D compiler // compiler log string log = builder.build(); The log should be in realtime to see where compilation takes longest etc. also to all above it would be good if there be some concept of multiple targets or jobs and ordering, to allow build stuff dependent on other stuff in one run Everything is compiled without beeing linked, order doesn't mean anything, because everything will be linked together.
Re: Build Script in D
On Friday, 11 January 2013 at 14:01:48 UTC, David wrote: also something like this for custom target: auto builder = Builder( homepath!./, arch!x86, mode!debug ) Doesn't work, these are compiler flags, which differ from compiler to compiler. You could make the builder call the compiler to set the flag, but I would move that directly to the compiler. // assuming all methods returns ref to self so it could be just simple calls builder.addSrcPath(path_to_src_folder_1); // or can be chained builder.addSrcPath(path_to_src_folder_2). addSrcPath(path_to_src_folder3); And how does chaining help? That makes everything just uglier. builder.addImportPath(path_to_imports); builder.addLinkLib(somelib.a); Need to be set for the compiler, A C compiler doesn't need the flags of a D compiler // compiler log string log = builder.build(); The log should be in realtime to see where compilation takes longest etc. also to all above it would be good if there be some concept of multiple targets or jobs and ordering, to allow build stuff dependent on other stuff in one run Everything is compiled without beeing linked, order doesn't mean anything, because everything will be linked together. well the topic says script in D, so i assume this is for D and not C(there is already cmake, make and so on), and this is possible to get compiler info in D ugly chaining is not so ugly, and is just an option, there is anyway with (...) construct in D log is was an example and not requirement, i just say that such class when used with CTFE somehow would be helpful to do easy compile with all dependencies, i.e. you only compile one target and using CTFE it compiles other, possibly messy stuff but maybe anyone need this... anyway that's just a wishlist, not a must have list =3
