This was raised in another thread, but I think this issue is fairly important - what is the status of CMake? Having three parallel build systems (homebrew buildtool, autotools and CMake) is at least awkward. I understand that migrating to CMake would allow us to remove the Windows build system. On the other hand, figuring out how to compile Inkscape on Windows using MinGW and MSYS would do the same.
Regards, Krzysztof Kosiński
I'm still unclear on the reason why we need to do this? bobs build tool works great...Whats the improvement moving from that to cmake? the only reason we have 3 is cos people are playing with cmake,
2008/12/29 Krzysztof Kosiński <tweenk.pl@...400...>
This was raised in another thread, but I think this issue is fairly important
- what is the status of CMake? Having three parallel build systems
(homebrew buildtool, autotools and CMake) is at least awkward. I understand that migrating to CMake would allow us to remove the Windows build system. On the other hand, figuring out how to compile Inkscape on Windows using MinGW and MSYS would do the same.
Regards, Krzysztof Kosiński
View this message in context: http://www.nabble.com/CMake-status-tp21209331p21209331.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
john cliff-2 wrote:
I'm still unclear on the reason why we need to do this? bobs build tool works great...Whats the improvement moving from that to cmake?
Having two parallel build systems means that people using one system will tend to break the one they don't use. Having only one means that such breakage will be uncommon (e.g. only when somebody checked in non-portable code or forgot to check whether it compiles at all). What I'm saying is that we should either remove the CMake system or move to it entirely and remove the autotools system.
Regards, Krzysztof Kosiński
On Monday 29 December 2008 19:17:16 Krzysztof Kosiński wrote:
john cliff-2 wrote:
I'm still unclear on the reason why we need to do this? bobs build tool works great...Whats the improvement moving from that to cmake?
Having two parallel build systems means that people using one system will tend to break the one they don't use. Having only one means that such breakage will be uncommon (e.g. only when somebody checked in non-portable code or forgot to check whether it compiles at all). What I'm saying is that we should either remove the CMake system or move to it entirely and remove the autotools system.
Regards, Krzysztof Kosiński
Krzysztof,
I have been main person working the CMake build system. It is broken currently the overall goal is to provide a uniform build process for all platforms. I have been spending most of my Inkscape time working on the 2Geom conversion maybe after it is complete I will most likely spend more time on it. Help is of course always welcome.
Joshua L. Blocher verbalshadow
-----Original Message----- From: Krzysztof Kosiński [mailto:tweenk.pl@...400...] Sent: dinsdag 30 december 2008 3:17 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] CMake status
john cliff-2 wrote:
I'm still unclear on the reason why we need to do this? bobs build tool works great...Whats the improvement moving from that to cmake?
Having two parallel build systems means that people using one system will tend to break the one they don't use. Having only one means that such breakage will be uncommon (e.g. only when somebody checked in non-portable code or forgot to check whether it compiles at all). What I'm saying is that we should either remove the CMake system or move to it entirely and remove the autotools system.
I think we had one build system when I started working on Inkscape which is about 2,5 years ago (right?). So if you really want to try to unify things, you should look there maybe. 2Geom uses CMake, and although it works on multiple platforms, there is always trouble on different platforms. Probably every system we can come up with has this. It's not that big a deal though. I think the build rarely breaks because of the different build systems (most often, a Windows builder forgets to add a file to Makefile_insert, one of the cool things that the windows buildtool does automatically). This is usually fixed promptly, thanks to the cool guys on the (for me) other side. New files are not added so frequently. (I don't quite get why the makefile list is inclusive, instead of making the whole thing exclusive so you can add files without having to think about it...)
More often cross platform build breaks are caused by #ifdef clauses that are not compiled on windows/linux, or because of some 'standard' include file that is not known on linux/windows. Build systems are not going to solve that.
This mail is sort of meant as a warning; I think most people like the build systems as they are now, and are very reluctant on changing their habits with it. So spend your time wisely :-) (I much rather have Joshua on 2geom conversion. I helped a bit with the CMake stuff, but it is even more annoying than the 2geom conversion, without a real reward in the end too I'm afraid)
Cheers, Johan
What are our goals for a build system? I propose that we want: -Unified: one build system serves all platforms -User Friendly: build system doesn't get in the way of users and testers daily work -Developer Friendly: Developers can easily learn enough to add to and modify the build
CMake was supposed to be easy to understand and learn and the same on all platforms.
Aaron Spike
J.B.C.Engelen wrote:
(I don't quite get why the makefile list is inclusive, instead of making the whole thing exclusive so you can add files without having to think about it...)
The rationale of Automake authors for not supporting wildcards is that it prevents broken commits where somebody forgot to svn add the crucial file. It also allows one to build different applications out of a single directory, like we do with inkscape and inkview. I'm not entirely convinced but I'll bear with it.
Regards, Krzysztof Kosiński
-----Original Message----- From: Krzysztof Kosiński [mailto:tweenk.pl@...400...] Sent: dinsdag 30 december 2008 23:34 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] CMake status
J.B.C.Engelen wrote:
(I don't quite get why the makefile list is inclusive, instead of making the whole thing exclusive so you can add files
without having
to think about it...)
The rationale of Automake authors for not supporting wildcards is that it prevents broken commits where somebody forgot to svn add the crucial file.
If I write #include "johan.h"
johan_method_do_stuff(1,2,3); in an existing file and forget to svn add it, it breaks the automake build.
It also allows one to build different applications out of a single directory, like we do with inkscape and inkview. I'm not entirely convinced but I'll bear with it.
build inkscape with *.*, exclude inkview.cpp.
build inkview with *.*, exclude inkscape.cpp.
It's much shorter and understandable than: build inkscape with blah.cpp blah2.cpp uninterestinginformationhere.cpp, etc...
Both inkscape and inkview will need my supercool "johan.cpp" file anyway. :P
To be honest, I stopped caring about the build system. :S
J.B.C.Engelen wrote:
build inkscape with *.*, exclude inkview.cpp. build inkview with *.*, exclude inkscape.cpp.
In reality, inkview should not reuse every file from Inkscape, just those it needs to work. It only shows that our codebase isn't very modular and there are many unnecessary dependencies.
I tried using MSYS on Windows to build Glib, but I failed at pkg-config, which complains about unknown escape charaters - probably a too-old g++ version. CMake on the other hand can only use MSVC projects on Windows, and I'm not going to install it since it's super-bloatware. I think that for now we have to put up with our existing build solution...
Regards, Krzysztof Kosiński
doesnt bobs tool work on linux?
2008/12/30 Krzysztof Kosiński <tweenk.pl@...400...>
J.B.C.Engelen wrote:
build inkscape with *.*, exclude inkview.cpp. build inkview with *.*, exclude inkscape.cpp.
In reality, inkview should not reuse every file from Inkscape, just those it needs to work. It only shows that our codebase isn't very modular and there are many unnecessary dependencies.
I tried using MSYS on Windows to build Glib, but I failed at pkg-config, which complains about unknown escape charaters - probably a too-old g++ version. CMake on the other hand can only use MSVC projects on Windows, and I'm not going to install it since it's super-bloatware. I think that for now we have to put up with our existing build solution...
Regards, Krzysztof Kosiński
View this message in context: http://www.nabble.com/CMake-status-tp21209331p21224999.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Krzysztof Kosiński wrote:
J.B.C.Engelen wrote:
build inkscape with *.*, exclude inkview.cpp. build inkview with *.*, exclude inkscape.cpp.
In reality, inkview should not reuse every file from Inkscape, just those it needs to work. It only shows that our codebase isn't very modular and there are many unnecessary dependencies.
I tried using MSYS on Windows to build Glib, but I failed at pkg-config, which complains about unknown escape charaters - probably a too-old g++ version.
Why do you need to build Glib? Isn't it included in our libs bundle?
CMake on the other hand can only use MSVC projects on Windows,
Please don't spread misinformation with such certainty. :-) CMake works just fine with MinGW. 2geom currently uses CMake and our normal Inkscape win32 libs and compiler bundles to build on Windows. Now, I'm not saying that the CMake setup to build Inkscape will work. It won't because it hasn't been finished.
Aaron Spike
Aaron Spike-2 wrote:
Why do you need to build Glib? Isn't it included in our libs bundle?
I needed it to test a bugfix for Glib for handling Unicode filenames as program arguments on Windows. Otherwise I wouldn't have bothered :)
Please don't spread misinformation with such certainty. :-) CMake works
just fine with MinGW.
There was no information about it on the CMake site - I assumed this is the only option. I'll investigate CMake some more.
-----Original Message----- From: Krzysztof Kosiński [mailto:tweenk.pl@...400...] Sent: woensdag 31 december 2008 0:50 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] CMake status
I tried using MSYS on Windows to build Glib, but I failed at pkg-config, which complains about unknown escape charaters - probably a too-old g++ version.
We have binaries of the libs we need built and ready here: https://svn.modevia.com/inkscape/devlibs
CMake on the other hand can only use MSVC projects on Windows, and I'm not going to install it since it's super-bloatware.
cmake -G "MinGW Makefiles" .
CMake works fine for lib2geom.
The problem we had with cmake was that it puts obj files in some special dir that is long, and then creates a commandline like: g++ verylongpathlisting/blah.o possiblyevenlongerpathname/blah2.o ... such that the cmdline is too long to work with windows/g++
Johan
Hi, I would like to use a widely used build-system on Windows as well. currently a build process lasts ages. I hope using some parallel build feature. I want make -j4
Adib. --- On Mon, Dec 29, 2008 at 10:26 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
This was raised in another thread, but I think this issue is fairly important
- what is the status of CMake? Having three parallel build systems (homebrew
buildtool, autotools and CMake) is at least awkward. I understand that migrating to CMake would allow us to remove the Windows build system. On the other hand, figuring out how to compile Inkscape on Windows using MinGW and MSYS would do the same.
Regards, Krzysztof Kosiński
View this message in context: http://www.nabble.com/CMake-status-tp21209331p21209331.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
the Adib wrote:
Hi, I would like to use a widely used build-system on Windows as well. currently a build process lasts ages. I hope using some parallel build feature. I want make -j4
MinGW make should support parallel builds. I have to test a GOption patch on Windows anyway, so I'll also check whether it's possible to compile Inkscape using MSYS.
Regards, Krzysztof Kosiński
participants (6)
-
unknown＠example.com -
Aaron Spike -
john cliff -
Joshua L. Blocher -
Krzysztof Kosiński -
the Adib