11:41 a.m.
Hello everyone,
I conducted an experiment in building Inkscape with Waf, redoing the
work I did a long time ago with a newer version (1.7.15) and using
more of its features. A correct build of Inkscape, with internal
libraries built separately, "inklib" built as a shared library, Bazaar
revision fetching and .po file compilation, requires less than 250
lines of Python script (!!!).
I read on some mailing lists that Debian refused to package some
software using Waf, because Debian considers shipping the "Waf binary"
to be incompatible with the DFSG. I circumvented this problem by
adding the Waf source distribution to the tree, which is a little
bigger, but DFSG-compliant and works exactly the same.
The code will be up shortly at lp:~tweenk/inkscape/waf-build, if
anyone wants to check it out.
Regards, Krzysztof
12:28 p.m.
Any quick instructions or tips? Are build options similar, such as
special flags?
Cheers,
Josh
On Fri, Jan 24, 2014 at 6:41 PM, Krzysztof Kosiński <tweenk.pl@...972.....> wrote:
Hello everyone,
I conducted an experiment in building Inkscape with Waf, redoing the
work I did a long time ago with a newer version (1.7.15) and using
more of its features. A correct build of Inkscape, with internal
libraries built separately, "inklib" built as a shared library, Bazaar
revision fetching and .po file compilation, requires less than 250
lines of Python script (!!!).
I read on some mailing lists that Debian refused to package some
software using Waf, because Debian considers shipping the "Waf binary"
to be incompatible with the DFSG. I circumvented this problem by
adding the Waf source distribution to the tree, which is a little
bigger, but DFSG-compliant and works exactly the same.
The code will be up shortly at lp:~tweenk/inkscape/waf-build, if
anyone wants to check it out.
Regards, Krzysztof
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg...
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
12:48 p.m.
2014/1/25 Josh Andler <scislac@...400...>:
Any quick instructions or tips? Are build options similar, such as
special flags?
Normal build:
./waf configure
./waf build
Option list:
./waf --help
The system is rather minimal at the moment, so I didn't test anything
besides vanilla building.
Regards, Krzysztof
2:35 p.m.
Just from a building point of view, nice and straightforward. I do
like seeing the status of where you're at in the process.
Cheers,
Josh
On Fri, Jan 24, 2014 at 7:48 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
2014/1/25 Josh Andler <scislac@...400...>:
> Any quick instructions or tips? Are build options similar, such as
> special flags?
Normal build:
./waf configure
./waf build
Option list:
./waf --help
The system is rather minimal at the moment, so I didn't test anything
besides vanilla building.
Regards, Krzysztof
5:10 a.m.
Em Sáb, 2014-01-25 às 03:41 +0100, Krzysztof Kosiński escreveu:
I conducted an experiment in building Inkscape with Waf, redoing the
work I did a long time ago with a newer version (1.7.15) and using
more of its features. A correct build of Inkscape, with internal
libraries built separately, "inklib" built as a shared library, Bazaar
revision fetching and .po file compilation, requires less than 250
lines of Python script (!!!).
That's impressive.
--
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker
4:01 a.m.
On 25-1-2014 3:41, Krzysztof Kosiński wrote:
Hello everyone,
I conducted an experiment in building Inkscape with Waf, redoing the
work I did a long time ago with a newer version (1.7.15) and using
more of its features. A correct build of Inkscape, with internal
libraries built separately, "inklib" built as a shared library, Bazaar
revision fetching and .po file compilation, requires less than 250
lines of Python script (!!!).
I read on some mailing lists that Debian refused to package some
software using Waf, because Debian considers shipping the "Waf binary"
to be incompatible with the DFSG. I circumvented this problem by
adding the Waf source distribution to the tree, which is a little
bigger, but DFSG-compliant and works exactly the same.
The code will be up shortly at lp:~tweenk/inkscape/waf-build, if
anyone wants to check it out.
Hi Krzysz,
Great that you are working on unifying the build system again. There is
a parallel effort using CMake, which you are aware of of course. CMake
is used by many projects, so it may be easier for Inkscapers to start
using that. That said, I don't feel very strongly about it.
What I think is important is that the system can target "ninja" or other
build systems besides "make". CMake can create makefiles for many
targets (makefiles, visual studio, ninja, ...) which is very nice and
would be an extra step forward for our buildsystem.
Can Waf do the same?
(ninja is speeding up 2geom compiles by an incredible amount, mostly
because 2geom has many executable targets (all the toys, etc). Don't
know what it will do for Inkscape.)
Cheers,
Johan
4:44 a.m.
2014-01-26 Johan Engelen <jbc.engelen@...2592...>:
Hi Krzysz,
Great that you are working on unifying the build system again. There is
a parallel effort using CMake, which you are aware of of course. CMake
is used by many projects, so it may be easier for Inkscapers to start
using that. That said, I don't feel very strongly about it.
What I think is important is that the system can target "ninja" or other
build systems besides "make". CMake can create makefiles for many
targets (makefiles, visual studio, ninja, ...) which is very nice and
would be an extra step forward for our buildsystem.
Can Waf do the same?
There is some support for generating MS Visual Studio project files,
so I guess it would be entirely possible to write a generator for
Ninja, but generally the premise of Waf is different than CMake. CMake
is a build system generator, while Waf is the build system itself - it
replaces 'make' completely.
The biggest advantages of Waf from my perspective:
1. It stores file hashes in a database which is persistent over runs,
so you can use wildcards to specify the files to build, and it will
figure out on its own that the wildcard includes new files which have
to be compiled. This is simply impossible in a system where state
information is stored only in file system attributes, such as make.
2. The build scripts use Python, which is a real programming language
with very high expressive power. By comparison, programming anything
even moderately complex in CMake is a bad joke.
3. As a consequence of 2, it is very easy to express complex tasks in
a very small amount of code. Basically everything, from simple
building, to maintenance tasks such as updating the potfiles, to
release tarball generation can be integrated in the build scripts as
Waf commands.
4. Since my first attempt, the documentation has improved massively -
there are fairly comprehensive API docs available online.
5. I have commit access, so I can immediately fix any bugs we encounter :)
(ninja is speeding up 2geom compiles by an incredible amount, mostly
because 2geom has many executable targets (all the toys, etc). Don't
know what it will do for Inkscape.)
A no-change rebuild of Inkscape (~1000 tasks) takes around half a
second on my machine, which is a lot faster than Autotools (I didn't
measure it precisely, but it takes several seconds).
As far as I know, Waf is substantially faster than SCons, Autotools
and make, but slower than lower level tools such as Ninja, Gyp and
Tup. However, the difference is not very noticeable for projects the
size of Inkscape, and IMO this drawback is outweighed by its ease of
use.
Regards, Krzysztof
5:08 a.m.
Thanks for the clarification.
I'm trying to use it on Windows now.
- Extra dependency = perl (installed ActivePerl, is free)
- It finds MSVC first, but I can tell it not to do that (how to set the
default? CXX env var does not work, as it still thinks that is MSVC...)
- It creates /build. Does it do out-of-source build automatically?
That'd be great.
- Now it errors because it cannot find 'glib-mkenums' (indeed, the
executable is not in our devlibs)
- I really hope we can set all defaults correctly on Windows, so we can
build from a new checkout with the same amount of effort as we do now
(almost zero).
Cheers,
Johan
On 26-1-2014 20:44, Krzysztof Kosiński wrote:
2014-01-26 Johan Engelen <jbc.engelen@...2592...>:
> Hi Krzysz,
> Great that you are working on unifying the build system again. There is
> a parallel effort using CMake, which you are aware of of course. CMake
> is used by many projects, so it may be easier for Inkscapers to start
> using that. That said, I don't feel very strongly about it.
>
> What I think is important is that the system can target "ninja" or other
> build systems besides "make". CMake can create makefiles for many
> targets (makefiles, visual studio, ninja, ...) which is very nice and
> would be an extra step forward for our buildsystem.
> Can Waf do the same?
There is some support for generating MS Visual Studio project files,
so I guess it would be entirely possible to write a generator for
Ninja, but generally the premise of Waf is different than CMake. CMake
is a build system generator, while Waf is the build system itself - it
replaces 'make' completely.
The biggest advantages of Waf from my perspective:
1. It stores file hashes in a database which is persistent over runs,
so you can use wildcards to specify the files to build, and it will
figure out on its own that the wildcard includes new files which have
to be compiled. This is simply impossible in a system where state
information is stored only in file system attributes, such as make.
2. The build scripts use Python, which is a real programming language
with very high expressive power. By comparison, programming anything
even moderately complex in CMake is a bad joke.
3. As a consequence of 2, it is very easy to express complex tasks in
a very small amount of code. Basically everything, from simple
building, to maintenance tasks such as updating the potfiles, to
release tarball generation can be integrated in the build scripts as
Waf commands.
4. Since my first attempt, the documentation has improved massively -
there are fairly comprehensive API docs available online.
5. I have commit access, so I can immediately fix any bugs we encounter :)
> (ninja is speeding up 2geom compiles by an incredible amount, mostly
> because 2geom has many executable targets (all the toys, etc). Don't
> know what it will do for Inkscape.)
A no-change rebuild of Inkscape (~1000 tasks) takes around half a
second on my machine, which is a lot faster than Autotools (I didn't
measure it precisely, but it takes several seconds).
As far as I know, Waf is substantially faster than SCons, Autotools
and make, but slower than lower level tools such as Ninja, Gyp and
Tup. However, the difference is not very noticeable for projects the
size of Inkscape, and IMO this drawback is outweighed by its ease of
use.
6:07 a.m.
On Sun, 2014-01-26 at 21:08 +0100, Johan Engelen wrote:
- I really hope we can set all defaults correctly on Windows, so we
can build from a new checkout with the same amount of effort as we do
now (almost zero).
With autotools? Even on Ubuntu, with apt-get build-deps and easy to
aquire bzr, it's more difficult than I was expecting.
I wanted to test the build times between my machine Celeron toshiba vs
my wife's new i7 System76 laptop. 4.5 hours vs 55 minutes. So, it's
certainly faster to build than it used to be, although I guess the bulk
of the time isn't make or autotools, but gcc.
But maybe if waf can compile things in a smarter way. Every time I
edited document.h, I has to wait a long time for the compile because it
currently compiles every included file (and I understand why it might
need to) but perhaps some kind of manual command to say `make document.o
only and relink`
I'd prefer waf because it's python, I wonder why there's a perl dep.
Martin,
6:54 a.m.
On 26-1-2014 22:07, Martin Owens wrote:
On Sun, 2014-01-26 at 21:08 +0100, Johan Engelen wrote:
> - I really hope we can set all defaults correctly on Windows, so we
> can build from a new checkout with the same amount of effort as we do
> now (almost zero).
With autotools? Even on Ubuntu, with apt-get build-deps and easy to
aquire bzr, it's more difficult than I was expecting.
On Windows, from scratch, it is:
- bzr checkout devlibs somewhere
- bzr checkout lp:inkscape somewhere-else
- fix up mingwenv.bat if you want (easy to see all "options" to get
started in one file)
- g++ buildtool.cpp -fopenmp -O3 -o btool.exe
- btool -j
- done
For a new branch if you already have a main branch:
- bzr checkout branch somewhere
- copy mingwenv.bat and btool.exe from your main branch
- btool -j
- done
No configuration parameters are needed to get started. The build is done
out-of-source automatically, and the built binaries will be "installed"
into ./build/inkscape folder. Pretty simple and IMO very convenient. I
very much want to preserve this build-"complexity" on Windows.
I wanted to test the build times between my machine Celeron toshiba
vs
my wife's new i7 System76 laptop. 4.5 hours vs 55 minutes. So, it's
certainly faster to build than it used to be, although I guess the bulk
of the time isn't make or autotools, but gcc.
55 mins on an i7 means that you are not doing a parallel build. Try
build -j (btool has to be built with -fopenmp), or make -j 20. (some
random number above the number of cores that you have, > cores+2 or smth
will do, btool -j does 20 by default). The laptop should feel slow when
it is compiling, and your battery should drain fast :)
Just tried again: clean build takes my i7 @ 3.4 GHz a little over 6 minutes.
(because of running more threads in parallel than the amount of cores,
the threads no longer wait for file loading, explaining why RAM-disk or
SSD did not seem to bring anything).
Cheers,
Johan
7:56 a.m.
2014-01-26 Johan Engelen <jbc.engelen@...2592...>:
Thanks for the clarification.
I'm trying to use it on Windows now.
- Extra dependency = perl (installed ActivePerl, is free)
Perl is a dependency of intltool-merge. AFAIK we don't need to use
intltool-merge on Windows, because we don't build a desktop file
there, so it's a question of further tweaking the build script. (Note
that I didn't do any testing on Windows yet, so I don't expect it to
work.)
- It finds MSVC first, but I can tell it not to do that (how to set
the
default? CXX env var does not work, as it still thinks that is MSVC...)
We can set the variable waflib.compiler_cxx.cxx_compiler to set the
compiler priority, e.g. add this before the functions:
from Tools import compiler_cxx
compiler_cxx.cxx_compiler['win32'] = ['g++', 'clang++']
I also thought about adding some magic code that detects what compiler
did you specify in the CXX variable and picks the appropriate Waf
tool, but I'm not sure whether this is generic enough to warrant
- It creates /build. Does it do out-of-source build automatically?
That'd be
great.
Yes, you can tweak the output directory by using --out at config time
or changing the 'out' variable in the wscript.
- Now it errors because it cannot find 'glib-mkenums'
(indeed, the
executable is not in our devlibs)
This is loaded by the tool "glib2" by default, but we don't use it, so
it's the same as with Perl - some tweaking is necessary.
- I really hope we can set all defaults correctly on Windows, so we
can
build from a new checkout with the same amount of effort as we do now
(almost zero).
In the earlier system, I did get to the point where saying "./waf
dist" created the installation directory exactly like btool. I think
this time around I'll be able to achieve that state much quicker.
2014-01-26 Vinícius dos Santos Oliveira <vini.ipsmaker@...400...>
Does it track include files as well? I did a simple test seconds ago
and CMake was able to track include files too.
Use case: You change a header file included by some two implementation files. The
implementation files are not changed, but the header file is changed. The implementation
files including this header file should be recompiled.
Yes, it does track include files. I used Waf for some other projects
before and never had an issue on that front.
2014-01-26 Martin Owens <doctormo@...400...>:
But maybe if waf can compile things in a smarter way. Every time I
edited document.h, I has to wait a long time for the compile because it
currently compiles every included file (and I understand why it might
need to) but perhaps some kind of manual command to say `make document.o
only and relink`
If you edit document.h, you must rebuild every file that includes
document.h - there is no way around that, in any build system in
existence. It is theoretically possible to check whether the edits
change API/ABI and only recompile then, but this would be incredibly
complex to implement; I don't even know whether this is possible at
all.
Regards, Krzysztof
9:17 a.m.
Em Dom, 2014-01-26 às 23:56 +0100, Krzysztof Kosiński escreveu:
2014-01-26 Martin Owens <doctormo@...400...>:
> But maybe if waf can compile things in a smarter way. Every time I
> edited document.h, I has to wait a long time for the compile because
it
> currently compiles every included file (and I understand why it
might
> need to) but perhaps some kind of manual command to say `make
document.o
> only and relink`
If you edit document.h, you must rebuild every file that includes
document.h - there is no way around that, in any build system in
existence. It is theoretically possible to check whether the edits
change API/ABI and only recompile then, but this would be incredibly
complex to implement; I don't even know whether this is possible at
all.
The problem will disturb less when we have modules[1] in C++.
Unfortunately, the spec was getting more complex after each iteration.
[1] http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf
--
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker
5:12 a.m.
Em Dom, 2014-01-26 às 20:44 +0100, Krzysztof Kosiński escreveu:
1. It stores file hashes in a database which is persistent over
runs,
so you can use wildcards to specify the files to build, and it will
figure out on its own that the wildcard includes new files which have
to be compiled. This is simply impossible in a system where state
information is stored only in file system attributes, such as make.
Does it track include files as well? I did a simple test seconds ago and
CMake was able to track include files too.
Use case: You change a header file included by some two implementation
files. The implementation files are not changed, but the header file is
changed. The implementation files including this header file should be
recompiled.
--
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker
6:11 a.m.
On 25-1-2014 3:41, Krzysztof Kosiński wrote:
Hello everyone,
I conducted an experiment in building Inkscape with Waf, redoing the
work I did a long time ago with a newer version (1.7.15) and using
more of its features. A correct build of Inkscape, with internal
libraries built separately, "inklib" built as a shared library, Bazaar
revision fetching and .po file compilation, requires less than 250
lines of Python script (!!!).
I read on some mailing lists that Debian refused to package some
software using Waf, because Debian considers shipping the "Waf binary"
to be incompatible with the DFSG. I circumvented this problem by
adding the Waf source distribution to the tree, which is a little
bigger, but DFSG-compliant and works exactly the same.
The code will be up shortly at lp:~tweenk/inkscape/waf-build, if
anyone wants to check it out.
Random idea: what would be superawesome if we could build a single file,
something like:
waf compile --file=johan.cpp --cxxflags="..."
that would only compile (!) johan.cpp with _extra_ cxxflags added. For
example to look at assembler/LLVM IR output.
:D
Cheers,
Johan
9:17 a.m.
2014-01-28 Johan Engelen <jbc.engelen@...2592...>:
Random idea: what would be superawesome if we could build a single
file,
something like:
waf compile --file=johan.cpp --cxxflags="..."
that would only compile (!) johan.cpp with _extra_ cxxflags added. For
example to look at assembler/LLVM IR output.
You can say ./waf build --files=src/johan.cpp to compile only that
file. (It also works with globs.) The more problematic part is
convincing Waf to produce assembly output, because it would require
changing the global definition of compilation tasks and disabling the
link tasks. However, I think implementing something like this would be
possible:
./waf build --assembly-output --files=src/johan.cpp
If you wanted to specify custom flags for some specific files at
configure time, that would be easier, but the wscript would have to be
written with this functionality in mind. E.g. you would have to define
a separate taskgen for each group of files that receives custom flags.
Regards, Krzysztof
7:46 a.m.
On 29-1-2014 1:17, Krzysztof Kosiński wrote:
2014-01-28 Johan Engelen <jbc.engelen@...2592...>:
> Random idea: what would be superawesome if we could build a single file,
> something like:
>
> waf compile --file=johan.cpp --cxxflags="..."
>
> that would only compile (!) johan.cpp with _extra_ cxxflags added. For
> example to look at assembler/LLVM IR output.
You can say ./waf build --files=src/johan.cpp to compile only that
file. (It also works with globs.) The more problematic part is
convincing Waf to produce assembly output, because it would require
changing the global definition of compilation tasks and disabling the
link tasks. However, I think implementing something like this would be
possible:
./waf build --assembly-output --files=src/johan.cpp
If you wanted to specify custom flags for some specific files at
configure time, that would be easier, but the wscript would have to be
written with this functionality in mind. E.g. you would have to define
a separate taskgen for each group of files that receives custom flags.
I'm afraid the --assembly-output won't cut it. Because immediately one
would want to tweak the compiler flags.
I think just being able to do ./waf build --files... is already good
enough. You can capture the cmdline invoke of the compiler, and simply
use that one line. (compile.lst on Windows already does a good job
listing all the commands for example)
So if it is too hard, too bad. I'll make do with what we have already.
Cheers,
Johan
7:36 p.m.
On Sat, 25 Jan 2014 03:41:32 +0100
Krzysztof Kosiński <tweenk.pl@...400...> wrote:
Hello everyone,
I conducted an experiment in building Inkscape with Waf, redoing the
work I did a long time ago with a newer version (1.7.15) and using
more of its features. A correct build of Inkscape, with internal
libraries built separately, "inklib" built as a shared library, Bazaar
revision fetching and .po file compilation, requires less than 250
lines of Python script (!!!).
I read on some mailing lists that Debian refused to package some
software using Waf, because Debian considers shipping the "Waf binary"
to be incompatible with the DFSG. I circumvented this problem by
adding the Waf source distribution to the tree, which is a little
bigger, but DFSG-compliant and works exactly the same.
Dear Krzysztof,
I've only just come across this thread, so pardon me if I ask you
what is waf and what problem does it seek to solve?
From what I've read of the thread, it looks like (yet another)
replacement for make. What is it in your mind that makes waf so
much better than make that it's worth switching to?
The way I see it, waf (like cmake) will make Inkscape harder to build
not easier. As others have pointed out, it introduces new dependencies
and, because it is unfamiliar to most people, it means they must spend a
lot of time digging into waf's source code to find out what it's doing
when it goes wrong. This isn't the best use of developer's time.
I'd be the first to admit that automake leaves a lot to be desired, but
it is pretty straightforward to get shot of its ugliness and
inefficiencies. I'd be happy to do this, but I don't want to upset
anyone.
Yours,
Is.
8:09 p.m.
On Thu, Jan 30, 2014 at 2:36 PM, Isobel Knowles wrote:
I've only just come across this thread, so pardon me if I ask
you
what is waf and what problem does it seek to solve?
http://inkscape.13.x6.nabble.com/Waf-build-branch-td2844228.html
Alexandre
9:14 p.m.
2014-01-30 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
On Thu, Jan 30, 2014 at 2:36 PM, Isobel Knowles wrote:
> I've only just come across this thread, so pardon me if I ask you
> what is waf and what problem does it seek to solve?
http://inkscape.13.x6.nabble.com/Waf-build-branch-td2844228.html
By the way, downsides 1, 2, 3 and 6 from that thread have been already
addressed.
Regards, Krzysztof
9:45 p.m.
2014-01-30 Martin Owens <doctormo@...400...>:
On Thu, 2014-01-30 at 13:14 +0100, Krzysztof Kosiński wrote:
> By the way, downsides 1, 2, 3 and 6 from that thread have been already
> addressed.
Did the original developer acquire sense or was it forked?
As far as I can see, mostly the former.
Regards, Krzysztof
9:36 p.m.
On 25/01/14 02:41, Krzysztof Kosiński wrote:
Hello everyone,
I conducted an experiment in building Inkscape with Waf, redoing
the work I did a long time ago with a newer version (1.7.15) and
using more of its features. A correct build of Inkscape, with
internal libraries built separately, "inklib" built as a shared
library, Bazaar revision fetching and .po file compilation,
requires less than 250 lines of Python script (!!!).
I read on some mailing lists that Debian refused to package some
software using Waf, because Debian considers shipping the "Waf
binary" to be incompatible with the DFSG. I circumvented this
problem by adding the Waf source distribution to the tree, which is
a little bigger, but DFSG-compliant and works exactly the same.
The code will be up shortly at lp:~tweenk/inkscape/waf-build, if
anyone wants to check it out.
Regards, Krzysztof
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In
Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg...
_______________________________________________
Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I use waf at work, and CMake on my open-source project (sigrok PulseView).
From my experience CMake is a lot easier to use and more widely used
than waf. We use waf at work, and it's ok - but not easy to use unless
you really know python.
Also CMake has a much larger community around it - hence support for
Ninja, MSVC etc., wheras we find ourselves mostly talking directly to
the Waf guy.
Waf is like a python library that can build your project, if you put
in the effort of scripting it to do what you want. So as I use it, it
feels like I'm doing a lot of things from scratch.
Also Debian refused to package waf because it wants to be a packaging
system which clashes with their own packaging system.
The downside of CMake is the rather weird language of CMake files.
Not trying to tell Inkscape what to do - but I may be one of the few
people who are using both.
Best Regards
Joel
9:45 p.m.
2014-01-30 Joel Holdsworth <joel@...1709...>:
From my experience CMake is a lot easier to use and more widely used
than waf. We use waf at work, and it's ok - but not easy to use unless
you really know python.
CMake requires you to learn a frustratingly weak and idiosyncratic
scripting language which is only useful in CMake (and even there
barely so), whereas learning Python is generally useful, especially to
a programmer coming from a Java / C / C++ background.
Also CMake has a much larger community around it - hence support for
Ninja, MSVC etc., wheras we find ourselves mostly talking directly to
the Waf guy.
That's true; on the other hand, it's much easier to add something to Waf.
Also Debian refused to package waf because it wants to be a
packaging
system which clashes with their own packaging system.
Debian refused to package Waf for different reasons:
1. Originally the Waf tarball contained non-free docs (CC-BY-ND or
something similar); it no longer contains them
2. The maintainer insisted that Waf should not be installed
system-wide due to potential incompatibilities between versions
3. Most projects included the "Waf binary", a compressed version of
Waf codw with stripped comments, which Debian says is incompatible
with DFSG; this can be avoided by including the source distribution,
which is only a little bigger.
The downside of CMake is the rather weird language of CMake files.
That's a pretty big downside IMO, see above.
All that being said, if there's a consensus we should use CMake, I'll
go along with that
Regards, Krzysztof
10:06 p.m.
On Thu, Jan 30, 2014 at 01:45:12PM +0100, Krzysztof Kosi??ski wrote:
2014-01-30 Joel Holdsworth <joel@...1709...>:
> From my experience CMake is a lot easier to use and more widely used
> than waf. We use waf at work, and it's ok - but not easy to use unless
> you really know python.
CMake requires you to learn a frustratingly weak and idiosyncratic
scripting language which is only useful in CMake (and even there
barely so), whereas learning Python is generally useful, especially to
a programmer coming from a Java / C / C++ background.
I'm going to second this, as a language cmake is plain ugly (up there
with php and apache config in ugliness :). For my own projects I've
ended up with a hand rolled build system in preference to cmake (or
worse, auto*). When a build tool is so hard to use for most
programmers that they write their own in preference, you know it's not
really working out.
If you want a programming language, use one :) We already have a
dependency on python.
> Also CMake has a much larger community around it - hence support
for
> Ninja, MSVC etc., wheras we find ourselves mostly talking directly to
> the Waf guy.
That's true; on the other hand, it's much easier to add something to
Waf.
Yes, a simple program that can be understood with general programming
knowledge is always a better choice in the long run. I'm also not
clear what benefits cmake really brings. My original attractions to
cmake were: Firstly, the efficient parallelisation, but since then I've
discovered I can write pretty much the same thing using python in a
few tens of lines. The second attraction was the idea that cmake
would have all the system integration stuff (find where the cairo
headers and libraries are, set the appropriate g++ flags); but we soon
found that support was spotty, and adding even trivial new rules was
an expedition into the land of pain. The third attraction to me was the
spiffy coloured build progress...
All that being said, if there's a consensus we should use CMake,
I'll
go along with that
I hope not. cmake was great for 2geom up to the point where we wanted
it to do something more than make. Then it was just a pain. I still
end up getting scislac or acspike to make changes to the cmake config
rather than fight its arcane and inconsistent programming language.
njh
4:02 a.m.
On Fri, 31 Jan 2014 00:06:38 +1100
Nathan Hurst <njh@...1927...> wrote:
On Thu, Jan 30, 2014 at 01:45:12PM +0100, Krzysztof Kosi??ski wrote:
> 2014-01-30 Joel Holdsworth <joel@...1709...>:
> > From my experience CMake is a lot easier to use and more widely
> > used than waf. We use waf at work, and it's ok - but not easy to
> > use unless you really know python.
>
> CMake requires you to learn a frustratingly weak and idiosyncratic
> scripting language which is only useful in CMake (and even there
> barely so), whereas learning Python is generally useful, especially
> to a programmer coming from a Java / C / C++ background.
I'm going to second this, as a language cmake is plain ugly (up there
with php and apache config in ugliness :). For my own projects I've
ended up with a hand rolled build system in preference to cmake (or
worse, auto*). When a build tool is so hard to use for most
programmers that they write their own in preference, you know it's not
really working out.
If you want a programming language, use one :) We already have a
dependency on python.
> > Also CMake has a much larger community around it - hence support
> > for Ninja, MSVC etc., wheras we find ourselves mostly talking
> > directly to the Waf guy.
>
> That's true; on the other hand, it's much easier to add something to
> Waf.
Yes, a simple program that can be understood with general programming
knowledge is always a better choice in the long run. I'm also not
clear what benefits cmake really brings. My original attractions to
cmake were: Firstly, the efficient parallelisation, but since then
I've discovered I can write pretty much the same thing using python
in a few tens of lines. The second attraction was the idea that cmake
would have all the system integration stuff (find where the cairo
headers and libraries are, set the appropriate g++ flags); but we soon
found that support was spotty, and adding even trivial new rules was
an expedition into the land of pain. The third attraction to me was
the spiffy coloured build progress...
> All that being said, if there's a consensus we should use CMake,
> I'll go along with that
I hope not. cmake was great for 2geom up to the point where we wanted
it to do something more than make. Then it was just a pain. I still
end up getting scislac or acspike to make changes to the cmake config
rather than fight its arcane and inconsistent programming language.
What exactly did you want to do during a build that make couldn't
accomplish, or are you talking about cmake's deficiencies?
I for one vote for something which keeps configuration separate from
building. It is easy to write and maintain multi-platform makefiles
for a project of inkscape's size and complexity, but only if the
configuration system is properly separated from the build system. Once
you start combining them like automake, cmake and waf do, it rapidly
evolves into a programming project all of its own. Although I make
no comment on its ability to configure a build, from what I've seen of
waf's command-line syntax, as a "make" system it looks like a step
backwards.
I know I'm only a user (and experienced make person), but the reason
this matters to me is my platform is sufficiently different to that of
the run-of-the-mill developer that I usually need to hack^H^H^H^Hport
UNIX packages before they'll compile on my machines. If inkscape starts
using waf or anything else that confuses configuration with building,
it's just makes it "a land of pain".
Yours,
Is.
PS. My offer to write some 'nice' makefiles is still open.
8:14 a.m.
On Thu, 30 Jan 2014 20:11:14 +0100
Johan Engelen <jbc.engelen@...2592...> wrote:
On 30-1-2014 20:02, Isobel Knowles wrote:
> PS. My offer to write some 'nice' makefiles is still open.
No-one is stopping you :-)
Make us dazzle...
:)
Johan
Dear Johan,
OK. Before I do, do you think you could tell me what it is you want
from the build? What are the essentials and what are the nice-to-haves?
Where do you see the problems in the current architecture and what are
its strengths?
I'm only after some pointers so I don't set off in the wrong direction.
I'll start the ball rolling with these:
- Documentation. People who are new to Inkscape should find it easy to
edit the makefiles.
- Separate configuration and build cleanly so when the configuration
phase doesn't do what you want for one reason or another, it is
straight-forward to manually configure the build options in one or
two files.
- Separate compilation and installation/packaging. Installation is
generally performed as root, and all too often in GNU software libtool
and the like get their teeth into a 'make install', turning it into
compilation job. This is wrong.
- An ordinary build job should do the minimum work in the minimum time.
For this I propose a flat makefile structure, perhaps composed of
included makefiles. Parallel makes like this perform correctly and
have no scalability issues whereas recursive makefiles are beset with
problems and complication.
- It should be simple to modify build flags and make alternative
targets for debugging purposes.
I wouldn't describe it as dazzling, but it's a start.
Yours,
Is.
11:49 a.m.
Hi,
compiling the subfolders into shared libraries would be interesting. This is
not possible currently.
The cmake-build branch already supports this and it runs everywhere except
on windows, but that's probably some problem with the toolchain.
Regards,
Markus
-----Ursprüngliche Nachricht-----
Von: Isobel Knowles [mailto:ik5@...2950...]
Gesendet: Freitag, 31. Januar 2014 00:15
An: Johan Engelen
Cc: inkscape-devel(a)lists.sourceforge.net
Betreff: Re: [Inkscape-devel] Waf build system, second try
On Thu, 30 Jan 2014 20:11:14 +0100
Johan Engelen <jbc.engelen@...2592...> wrote:
On 30-1-2014 20:02, Isobel Knowles wrote:
> PS. My offer to write some 'nice' makefiles is still open.
No-one is stopping you :-)
Make us dazzle...
:)
Johan
Dear Johan,
OK. Before I do, do you think you could tell me what it is you want from the
build? What are the essentials and what are the nice-to-haves?
Where do you see the problems in the current architecture and what are its
strengths?
I'm only after some pointers so I don't set off in the wrong direction.
I'll start the ball rolling with these:
- Documentation. People who are new to Inkscape should find it easy to
edit the makefiles.
- Separate configuration and build cleanly so when the configuration
phase doesn't do what you want for one reason or another, it is
straight-forward to manually configure the build options in one or
two files.
- Separate compilation and installation/packaging. Installation is
generally performed as root, and all too often in GNU software libtool
and the like get their teeth into a 'make install', turning it into
compilation job. This is wrong.
- An ordinary build job should do the minimum work in the minimum time.
For this I propose a flat makefile structure, perhaps composed of
included makefiles. Parallel makes like this perform correctly and
have no scalability issues whereas recursive makefiles are beset with
problems and complication.
- It should be simple to modify build flags and make alternative
targets for debugging purposes.
I wouldn't describe it as dazzling, but it's a start.
Yours,
Is.
----------------------------------------------------------------------------
--
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import a
virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg...
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
12:41 a.m.
On Thu, 2014-01-30 at 13:45 +0100, Krzysztof Kosiński wrote:
All that being said, if there's a consensus we should use CMake,
I'll
go along with that
Python on the design of CMake and autotools:
https://www.youtube.com/watch?v=e2PyeXRwhCE
I vote for waf, if there was ever a vote. ;-)
Martin,
3345
days inactive
3352
days old
inkscape-devel@lists.inkscape.org
28 comments
10 participants
participants (10)
-
Alexandre Prokoudine -
Isobel Knowles -
Joel Holdsworth -
Johan Engelen -
Josh Andler -
Krzysztof Kosiński -
Markus Engel -
Martin Owens -
Nathan Hurst -
Vinícius dos Santos Oliveira