Use of MINGW64 (minor)
Hi Everyone,
I am on the process to resume my work on Inkscape I did about css.
I was using svn, now I have a new computer so I start again fresh with bazaar, so far so good.
Since its running Windows 7 x64 I decided to give a try to mingw64.
Compiling btool went fine, however when running it allocated 4 gig of memory and stalls.
A quick look didn’t help figure out what could be the cause and now I revert to x32.
Now I wonder what is the ground of using btool today. Is it still a necessity ? Other projects compile both on Windows and Linux without any specific tool. It would also help to benefit from a real incremental build.
Any ideas of what was already tried around btool ?
Also if there is already some ideas of having Inkscape addins let me know. I would like some ability to add attributes to svg files like scripts or rdf attributes.
-Bruno
Bruno Winck Email: mailto:bwinck@...2633... bwinck@...2632...
Blog: http://www.kneaver.com/ http://www.kneaver.com/blog Kneaver Corp http://www.kneaver.com/ http://www.kneaver.com/
Twitter:http://twitter.com/kneaver skype:brunowinck SKYPE:brunowinck PH: +1 (415) 749 5850 CELL: +1 (415) 513 3160
2011/6/8 Bruno Winck <bw@...2632...>
Any ideas of what was already tried around btool ?
I ported the build system to Waf some time ago, but I used a very customized version of Waf 1.5, so in the end I ddn't put it in trunk. The system worked well on both Linux and Windows. The new Waf 1.6 has a lot more of the needed functionality in core so I guess it would be more feasible to do this now.
Regards, Krzysztof
On Jun 8, 2011, at 1:14 PM, Bruno Winck wrote:
Hi Everyone,
I am on the process to resume my work on Inkscape I did about css.
I was using svn, now I have a new computer so I start again fresh with bazaar, so far so good. Since its running Windows 7 x64 I decided to give a try to mingw64. Compiling btool went fine, however when running it allocated 4 gig of memory and stalls. A quick look didn’t help figure out what could be the cause and now I revert to x32.
Now I wonder what is the ground of using btool today. Is it still a necessity ? Other projects compile both on Windows and Linux without any specific tool. It would also help to benefit from a real incremental build.
Actually most projects do use some build tool of one form or another. At the moment the main candidate for cross-platform building is cmake.
There has been some effort at exploring this, but the main cmake developers have said it should be a straightforward to move to.
We've looked into a few different tools, but the others have various blocking issues.
2011/6/9 Jon Cruz <jon@...18...>:
Actually most projects do use some build tool of one form or another. At the moment the main candidate for cross-platform building is cmake.
CMake is a popular choice, but I don't understand its popularity. Its scripting language is frustratingly weak. You have to write hundreds of lines to do anything even moderately complex. The syntax is bizarre, sometimes case-sensitive and sometimes not. It would also add another build dependency.
Waf is a 100 kB script that allows you to use Python as the build scripting language. It uses only Python functionality, and we already have the required version of Python in the devlibs. Another plus is that it mimicks Autotools (configure, build, clean, distclean). And those are not theoretical considerations, I have successfully built Inkscape on both Windows and Linux using it and I see no reason why it wouldn't work on OSX. Adding features like revision number in the about box, autogenerated sources, etc. was easy, as there are many examples available.
Regards, Krzysztof
Hi Krzysztof,
Could you share with us what the source build file would look like ? Even if we cannot run it, just to see what it looks like.
Surely btool is a nice work but maintaining 9000 lines of c++ is a job by itself. The more so if it only used for the Windows build.
On other project we simply use make, not so bad and everyone knows how to use it, recognized by many frameworks. You can always have a few scripts in whatever language you like to do some configuration. But for simple task like saving a .h file and rebuilding as quickly as possible it works fine.
If some cleanup work and refactoring is planned a good build tool is a benefit.
Now I am open.
Bruno Winck Email: bwinck@...2632... Blog: http://www.kneaver.com/blog Kneaver Corp http://www.kneaver.com/ Twitter:http://twitter.com/kneaver SKYPE:brunowinck PH: +1 (415) 749 5850 CELL: +1 (415) 513 3160
-----Original Message----- From: Krzysztof Kosinski [mailto:tweenk.pl@...400...] Sent: Thursday, June 09, 2011 3:17 PM To: Jon Cruz Cc: Bruno Winck; inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Use of MINGW64 (minor)
2011/6/9 Jon Cruz <jon@...18...>:
Actually most projects do use some build tool of one form or another. At the moment the main candidate for cross-platform building is cmake.
CMake is a popular choice, but I don't understand its popularity. Its scripting language is frustratingly weak. You have to write hundreds of lines to do anything even moderately complex. The syntax is bizarre, sometimes case-sensitive and sometimes not. It would also add another build dependency.
Waf is a 100 kB script that allows you to use Python as the build scripting language. It uses only Python functionality, and we already have the required version of Python in the devlibs. Another plus is that it mimicks Autotools (configure, build, clean, distclean). And those are not theoretical considerations, I have successfully built Inkscape on both Windows and Linux using it and I see no reason why it wouldn't work on OSX. Adding features like revision number in the about box, autogenerated sources, etc. was easy, as there are many examples available.
Regards, Krzysztof
2011/6/9 Bruno Winck <bw@...2632...>:
Could you share with us what the source build file would look like ? Even if we cannot run it, just to see what it looks like.
My work is at lp:~tweenk/inkscape/waf-build It uses a heavily customized Waf. If I changed to Waf 1.6, a lot of the content in InkWaf.py would be unnecessary.
On other project we simply use make, not so bad and everyone knows how to use it, recognized by many frameworks. You can always have a few scripts in whatever language you like to do some configuration. But for simple task like saving a .h file and rebuilding as quickly as possible it works fine.
Using plain make becomes really painful when you have more than a few files with dependencies on each other. The whole point of all the build systems around is to automate dependency generation.
Regards, Krzysztof
True about dependency, however keep in mind that btool.exe is doing limited work in terms of partial rebuilt. Now you can imagine two steps : dependency generation then make. Dependency generation don't need to be done all the time and on all platform so a trade of is may be possible.
gcc itself for example can produce dependency files (-M option) that can be used inside make.
It is may be easy to generate other dependency files for other steps. Some of them can be simple sed and may be they exists already.
What disturbs me with make is the old fashion format. I would prefer an xml format, easier to generate, to parse.
Ant would require a java runtime and support for gcc is not native.
I take a look at the waf scripts. It's new to me. I see a benefit : portability, I am surprised it is very procedural. Large work.
It is : Wscript Waf.bat Waf InkWaf.py
Is there more ?
Still I am somehow wondering about all the wscript files. Any developer willing to add a file will have to know how to modify them and so know at least something about waf and python.
Very occasional helping hands like me could be blocked by that. Specially if it breaks. This is what I face now with btool. I use a recent gcc and so it throw all types of warning and some of them are justified. Uninstalling gcc , pain, setting new compilation options : difficult with btool, so it all kind of questions and you don't want to have a virtual machine per open source project you work on.
Sincerely, -Bruno
Bruno Winck Email: bwinck@...2632... Blog: http://www.kneaver.com/blog Kneaver Corp http://www.kneaver.com/ Twitter:http://twitter.com/kneaver SKYPE:brunowinck PH: +1 (415) 749 5850 CELL: +1 (415) 513 3160
-----Original Message----- From: Krzysztof Kosinski [mailto:tweenk.pl@...400...] Sent: Thursday, June 09, 2011 9:57 PM To: Bruno Winck Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Use of MINGW64 (minor)
2011/6/9 Bruno Winck <bw@...2632...>:
Could you share with us what the source build file would look like ? Even if we cannot run it, just to see what it looks like.
My work is at lp:~tweenk/inkscape/waf-build It uses a heavily customized Waf. If I changed to Waf 1.6, a lot of the content in InkWaf.py would be unnecessary.
On other project we simply use make, not so bad and everyone knows how to use it, recognized by many frameworks. You can always have a few scripts in whatever language you like to do some configuration. But for simple task like saving a .h file and rebuilding as quickly as possible it works fine.
Using plain make becomes really painful when you have more than a few files with dependencies on each other. The whole point of all the build systems around is to automate dependency generation.
Regards, Krzysztof
2011/6/10 Bruno Winck <bw@...2632...>:
I take a look at the waf scripts. It's new to me. I see a benefit : portability, I am surprised it is very procedural. Large work.
The build is not procedural. When the build() function of the wscript executes, it only defines the tasks. The compilation happens *after* the build() function returns.
It is : Wscript Waf.bat Waf InkWaf.py
Is there more ?
There are also the wscripts in subdirectories, but most of them are recursion stubs.
Still I am somehow wondering about all the wscript files. Any developer willing to add a file will have to know how to modify them and so know at least something about waf and python.
Same can be said about basically any build system in existence, including btool.exe. The advantages of Waf in this regard are that file moves do not require any modification to the build system (at least the way I implemented it), and it works on all platforms we support (Windows, Unix, OSX).
Regards, Krzysztof
Hello,
Seems that we don't have the perfect solution satisfying everyone.
I am new to that, with the same problems in other projects with also custom tools but working on both Linux and Windows.
I gave cmake a try. A brainless try, simply following instructions. I already quite happy I got something.
Go to http://www.cmake.org/cmake/resources/software.html
Download cmake installer win32
During setup click "register cmake in path for all users".
go to
http://wiki.inkscape.org/wiki/index.php/CMake
follow instructions
mkdir buildinkscape
cd buildinkscape
cmake ./path/to/inkscape/sources
make
------------------------------- C:\Project\OpenSource\inkscape>mkdir buildinkscape
C:\Project\OpenSource\inkscape>cd buildinkscape
C:\Project\OpenSource\inkscape\buildinkscape>cmake .. -- Building for: Visual Studio 9 2008 -- Check for working C compiler using: Visual Studio 9 2008 Could not register CMake's Visual Studio macros file 'CMakeVSMacros2.vsmacros' w hile Visual Studio is running. Please exit all running instances of Visual Studi o before continuing.
CMake needs to register Visual Studio macros when its macros file is updated or when it detects that its current macros file is no longer registered with Visual Studio.
-- Check for working C compiler using: Visual Studio 9 2008 -- works -- Detecting C compiler ABI info Could not register CMake's Visual Studio macros file 'CMakeVSMacros2.vsmacros' w hile Visual Studio is running. Please exit all running instances of Visual Studi o before continuing.
CMake needs to register Visual Studio macros when its macros file is updated or when it detects that its current macros file is no longer registered with Visual Studio.
-- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Visual Studio 9 2008 Could not register CMake's Visual Studio macros file 'CMakeVSMacros2.vsmacros' w hile Visual Studio is running. Please exit all running instances of Visual Studi o before continuing.
CMake needs to register Visual Studio macros when its macros file is updated or when it detects that its current macros file is no longer registered with Visual Studio.
-- Check for working CXX compiler using: Visual Studio 9 2008 -- works -- Detecting CXX compiler ABI info Could not register CMake's Visual Studio macros file 'CMakeVSMacros2.vsmacros' w hile Visual Studio is running. Please exit all running instances of Visual Studi o before continuing.
CMake needs to register Visual Studio macros when its macros file is updated or when it detects that its current macros file is no longer registered with Visual Studio.
-- Detecting CXX compiler ABI info - done -- Creating build files in: C:/Project/OpenSource/inkscape/buildinkscape -- Some or all of the gtk libraries were not found. (missing: GTK2_GTK_LIBRARY GTK2_GTK_INCLUDE_DIR GTK2_GLIB_INCLUDE_DIR GTK2_GLIBCONFIG_INCLUDE_DIR GTK2_GLIB _LIBRARY GTK2_GDK_INCLUDE_DIR GTK2_GDKCONFIG_INCLUDE_DIR GTK2_GDK_LIBRARY) -- Some or all of the gtkmm libraries were not found. (missing: GTK2_GTKMM_LIBR ARY GTK2_GTKMM_INCLUDE_DIR GTK2_GTKMMCONFIG_INCLUDE_DIR GTK2_GLIBMM_INCLUDE_DIR GTK2_GLIBMMCONFIG_INCLUDE_DIR GTK2_GLIBMM_LIBRARY GTK2_GDKMM_INCLUDE_DIR GTK2_GD KMMCONFIG_INCLUDE_DIR GTK2_GDKMM_LIBRARY) CMake Error at CMakeScripts/FindXML2.cmake:82 (message): Could not find XML2 Call Stack (most recent call first): CMakeScripts/DefineDependsandFlags.cmake:6 (find_package) CMakeLists.txt:15 (INCLUDE)
-- Configuring incomplete, errors occurred!
C:\Project\OpenSource\inkscape\buildinkscape>
---------------------------------
Reading cmake documentation I agree that I didn't see the language as specially attractive. What I hope is that some macros take nicely care of disperancies between linux and windows. This is why I wanted to try.
It seems to me that the hardest work in all btool, cmake and waf is to find the location and release of various libraries.
Something we do only from time to time while partial rebuild for compilation and debug are done hundreds of time per day.
I fully agree with Krzysztof about the eventual need of scripts to solve nasty things. And yes if it is not straightforward in cmake why not calling a python script. Keeping cmake just a the framework and skeleton. That would give best of both world. If you look into buildtool.cpp 7000 lines out of 9000 are standard libraries (xml, uri) that cmake could replace and several templates and things very specific to inkscape. This could be a few python scripts that can be debugged separately and are part of the source.
I was thinking of things like " FindBoost.cmake" also that needs constant updates (it is for 1.36 on inkscape cmake while Boost is 1.46). But specifically such files are maintained by others so it's a shared effort. Luckily because it doesn't look pleasant to do. You get it in CMake 2.8\share\cmake-2.8\Modules. So IMO it should be removed from inkscape/CMakeScripts or at least moved to devlibs.
FYI: Generating vcproj is pretty easy since we just want to have a list of files. It's an xml tree with relative paths.
<?xml version="1.0" encoding="Windows-1252"?> <VisualStudioProject ProjectType="Visual C++" Version="9.00" Name="KKKKHelper" ProjectGUID="{33A1B193-CC14-4AF9-A559-F8F4FFF39950}" > <Platforms> <Platform Name="Win32" /> </Platforms> <Files> <File RelativePath=".\DesignNotes.txt" > </File> </Files> </VisualStudioProject>
Bruno Winck Email: bwinck@...2632... Blog: http://www.kneaver.com/blog Kneaver Corp http://www.kneaver.com/ Twitter:http://twitter.com/kneaver SKYPE:brunowinck PH: +1 (415) 749 5850 CELL: +1 (415) 513 3160
-----Original Message----- From: Krzysztof Kosinski [mailto:tweenk.pl@...400...] Sent: Monday, June 13, 2011 12:26 AM To: Bruno Winck Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Use of MINGW64 (minor)
2011/6/10 Bruno Winck <bw@...2632...>:
I take a look at the waf scripts. It's new to me. I see a benefit : portability, I am surprised it is very procedural. Large work.
The build is not procedural. When the build() function of the wscript executes, it only defines the tasks. The compilation happens *after* the build() function returns.
It is : Wscript Waf.bat Waf InkWaf.py
Is there more ?
There are also the wscripts in subdirectories, but most of them are recursion stubs.
Still I am somehow wondering about all the wscript files. Any developer willing to add a file will have to know how to modify them and so know at least something about waf and python.
Same can be said about basically any build system in existence, including btool.exe. The advantages of Waf in this regard are that file moves do not require any modification to the build system (at least the way I implemented it), and it works on all platforms we support (Windows, Unix, OSX).
Regards, Krzysztof
Back my build question.
Looking into cmake I came across the fact that mysql changed from autotools to cmake. Let's say this is a inspiring project so if they did they surely had some reasons. What I can see is that building MySQL on windows looks easy now.
I found this page http://forge.mysql.com/wiki/Autotools_to_CMake_Transition_Guide http://forge.mysql.com/wiki/CMake which give an example of how would look similar pages for Inkscape if cmake was retained.
I am not enthusiast for cmake but after a couple of hours I didn't really find the next marvel. Seems like developers are like the shoemaker (shoemaker's son always goes barefoot).
Something I couldn't get is where to find for the original master build file.
How is the one for windows maintained from the one for unix.
Sincerely, -Bruno
Bruno Winck Email: bwinck@...2632... Blog: http://www.kneaver.com/blog Kneaver Corp http://www.kneaver.com/ Twitter:http://twitter.com/kneaver SKYPE:brunowinck PH: +1 (415) 749 5850 CELL: +1 (415) 513 3160
-----Original Message----- From: Bruno Winck [mailto:bw@...2632...] Sent: Friday, June 10, 2011 12:31 AM To: Krzysztof Kosinski Cc: inkscape-devel@lists.sourceforge.net Subject: RE: [Inkscape-devel] Use of MINGW64 (minor)
True about dependency, however keep in mind that btool.exe is doing limited work in terms of partial rebuilt. Now you can imagine two steps : dependency generation then make. Dependency generation don't need to be done all the time and on all platform so a trade of is may be possible.
gcc itself for example can produce dependency files (-M option) that can be used inside make.
It is may be easy to generate other dependency files for other steps. Some of them can be simple sed and may be they exists already.
What disturbs me with make is the old fashion format. I would prefer an xml format, easier to generate, to parse.
Ant would require a java runtime and support for gcc is not native.
I take a look at the waf scripts. It's new to me. I see a benefit : portability, I am surprised it is very procedural. Large work.
It is : Wscript Waf.bat Waf InkWaf.py
Is there more ?
Still I am somehow wondering about all the wscript files. Any developer willing to add a file will have to know how to modify them and so know at least something about waf and python.
Very occasional helping hands like me could be blocked by that. Specially if it breaks. This is what I face now with btool. I use a recent gcc and so it throw all types of warning and some of them are justified. Uninstalling gcc , pain, setting new compilation options : difficult with btool, so it all kind of questions and you don't want to have a virtual machine per open source project you work on.
Sincerely, -Bruno
Bruno Winck Email: bwinck@...2632... Blog: http://www.kneaver.com/blog Kneaver Corp http://www.kneaver.com/ Twitter:http://twitter.com/kneaver SKYPE:brunowinck PH: +1 (415) 749 5850 CELL: +1 (415) 513 3160
-----Original Message----- From: Krzysztof Kosinski [mailto:tweenk.pl@...400...] Sent: Thursday, June 09, 2011 9:57 PM To: Bruno Winck Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Use of MINGW64 (minor)
2011/6/9 Bruno Winck <bw@...2632...>:
Could you share with us what the source build file would look like ? Even if we cannot run it, just to see what it looks like.
My work is at lp:~tweenk/inkscape/waf-build It uses a heavily customized Waf. If I changed to Waf 1.6, a lot of the content in InkWaf.py would be unnecessary.
On other project we simply use make, not so bad and everyone knows how to use it, recognized by many frameworks. You can always have a few scripts in whatever language you like to do some configuration. But for simple task like saving a .h file and rebuilding as quickly as possible it works fine.
Using plain make becomes really painful when you have more than a few files with dependencies on each other. The whole point of all the build systems around is to automate dependency generation.
Regards, Krzysztof
On Jun 9, 2011, at 6:17 AM, Krzysztof Kosiński wrote:
2011/6/9 Jon Cruz <jon@...18...>:
Actually most projects do use some build tool of one form or another. At the moment the main candidate for cross-platform building is cmake.
CMake is a popular choice, but I don't understand its popularity. Its scripting language is frustratingly weak. You have to write hundreds of lines to do anything even moderately complex. The syntax is bizarre, sometimes case-sensitive and sometimes not. It would also add another build dependency.
Waf is a 100 kB script that allows you to use Python as the build scripting language. It uses only Python functionality, and we already have the required version of Python in the devlibs. Another plus is that it mimicks Autotools (configure, build, clean, distclean). And those are not theoretical considerations, I have successfully built Inkscape on both Windows and Linux using it and I see no reason why it wouldn't work on OSX. Adding features like revision number in the about box, autogenerated sources, etc. was easy, as there are many examples available.
Among the issues is that CMake is well established, while Waf is a bit newer and still getting going.
CMake has a larger development team, while Waf is mainly a one-man project.
There is a much larger community for CMake of people who can lend a hand or help us with it in general.
Waf was extending then replacing SCons. Many consider the architecture to be sub-optimal from that.
Many people consider that Waf exposes an entire general purpose language to be a negative as opposed to a positive. (this point is probably open for discussion)
Waf and it's proponents point out that CMake doesn't support "distclean" as a negative. CMake, on the other hand, points out that needing to have "distclean" to begin with is a negative.
CMake was picked up by Scribus among other related projects.
We have both key people from CMake and people from using projects such as Scribus volunteering to help us move to and maintain a CMake build. (Ongoing support of a system is probably a key factor)
CMake can create 'native' build results so that one can use Dev Studio on windows, XCode on Mac, etc.
And finally one of the biggest blockers is that the person in charge of Waf has stated that some changes we need will not be accepted into Waf. So if we do want to use it we will end up having to fork and maintain our own custom branch of the project. That in and of itself will be a large burden over even a short bit of time.
If anyone is interested in a good overview of CMake, Floss Weekly covered it in episode 111 of the podcast:
2011/6/10 Jon Cruz <jon@...18...>:
Among the issues is that CMake is well established, while Waf is a bit newer and still getting going.
So is Autotools, but I think we all agree that it sucks badly.
CMake has a larger development team, while Waf is mainly a one-man project.
That's true but it's rather easy to get commit access. Actually I have commit access to Waf.
There is a much larger community for CMake of people who can lend a hand or help us with it in general.
Waf is simple enough that I figured it out all on my own, though I admit the depth of documentation not as good as CMake.
Waf was extending then replacing SCons. Many consider the architecture to be sub-optimal from that.
Waf is an entirely different architecture that addresses most of the shortcomings of SCons, in particular its performance on large builds is far better than SCons or Autotools.
Many people consider that Waf exposes an entire general purpose language to be a negative as opposed to a positive. (this point is probably open for discussion)
Sooner or later there will be a task that requires you to use some "general purpose" feature like arrays, and you will end up either calling an external program or adding a clumsy scripting language to the build system. CMake is the perfect example: its programming constructs are annoyingly weak and tedious to use. Providing full access to Python is the least evil way of solving this problem: we have many extensions written in Python, so there's no overhead involved in learning an extra language just for the build system like there is with Autotools and CMake, and all the features are there in case we ever need them.
Waf and it's proponents point out that CMake doesn't support "distclean" as a negative. CMake, on the other hand, points out that needing to have "distclean" to begin with is a negative.
"distclean" in Waf basically removes the build directory and the hidden wafpickle file, so it's only a shortcut.
CMake was picked up by Scribus among other related projects.
Waf was picked up by Ardour, Samba and JACK. http://code.google.com/p/waf/wiki/ProjectsUsingWaf
We have both key people from CMake and people from using projects such as Scribus volunteering to help us move to and maintain a CMake build. (Ongoing support of a system is probably a key factor)
The CMake system is festering in the trunk for a few years and nobody stepped up to bring it to feature parity with Autotools. Meanwhile I added several features not present in the Autotools system (such as support for separate debugging symbols for all platforms) working alone, with some occasional help from the maintainer.
CMake can create 'native' build results so that one can use Dev Studio on windows, XCode on Mac, etc.
Waf can also use the Microsoft compilers, Intel C++ Compiler, and XCode GCC, though it doesn't generate things such as Visual Studio workspaces.
And finally one of the biggest blockers is that the person in charge of Waf has stated that some changes we need will not be accepted into Waf. So if we do want to use it we will end up having to fork and maintain our own custom branch of the project. That in and of itself will be a large burden over even a short bit of time.
These changes appeared in Waf 1.6 as far as I can tell, in particular there is support for Python 2.x. Dropping support for Python 2.x in Waf 1.6 was my main beef with this project, but the maintainer reconsidered this idea.
I don't want to push this against everyone, but I have worked a bit with all relevant build systems (Autotools, CMake, Waf) and I think Waf is the easiest one to use, and also the least complex. Autotools is a convoluted mess that barely works and I doubt anyone understands it. CMake would be good if its scripting language wasn't so completely useless.
Regards, Krzysztof
A general remark in this discussion on build systems: I think your time is best spent elsewhere.
I tried to get CMake going on Windows, and in the end it did not work because the final commandline to link it all was too large. I did not know how to solve it, and frankly, was no longer sure what exactly we would gain from the whole effort to convert the build mechanism.
I do not want to use cygwin, or other uncomfortable tools, and I can only hope I will be happy to whatever you guys decide to spend many hours on... Since Krzysztof already seems to have spent these hours successfully, why don't we go with that for a while? Whichever system we choose, in a couple of years someone will again bring up an argument about changing the build system.
Cheers, Johan
2011/6/14 Johan Engelen <jbc.engelen@...2592...>:
I tried to get CMake going on Windows, and in the end it did not work because the final commandline to link it all was too large. I did not know how to solve it, and frankly, was no longer sure what exactly we would gain from the whole effort to convert the build mechanism.
1. Building on Windows on multicore systems could be up to 8x faster. 2. We would no longer need to maintain two separate build systems for Unix and Windows. 3. There are many useful build features that are a nightmare to implement in Autotools but fairly easy in Waf or CMake, for example the authors list in the About dialog could be generated from the AUTHORS file.
Since Krzysztof already seems to have spent these hours successfully, why don't we go with that for a while?
I would need to update my branch and make it work with unmodified Waf 1.6, so it's not ready for general use yet.
Regards, Krzysztof
participants (4)
-
Bruno Winck -
Johan Engelen -
Jon Cruz -
Krzysztof Kosiński