Quantcast

Waf build branch

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Waf build branch

Krzysztof Kosiński
I pushed the Waf build system branch as:

lp:~tweenk/inkscape/waf-build

I would enjoy if someone tested it on Mac OS X and Windows, and
reported how it doesn't work. :)

The commands to build Inkscape are (in the top level source directory):
./waf configure
./waf build

Things that should work on Linux:
- building
- updating translation templates (via ./waf i18n)
- installation

Regards, Krzysztof

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Waf build branch

Michal Suchanek-2
2009/12/31 Krzysztof Kosiński <[hidden email]>:

> I pushed the Waf build system branch as:
>
> lp:~tweenk/inkscape/waf-build
>
> I would enjoy if someone tested it on Mac OS X and Windows, and
> reported how it doesn't work. :)
>
> The commands to build Inkscape are (in the top level source directory):
> ./waf configure
> ./waf build
>
> Things that should work on Linux:
> - building
> - updating translation templates (via ./waf i18n)
> - installation
>

OMG why?

I know autotools suck but my limited experience with waf so far is
that it sucks even more.

Care to share any potential advantages (or a pointer to a place where
they are listed) ?

Thanks

Michal

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Waf build branch

Krzysztof Kosiński
W dniu 8 stycznia 2010 17:58 użytkownik Michal Suchanek
<[hidden email]> napisał:
> I know autotools suck but my limited experience with waf so far is
> that it sucks even more.
>
> Care to share any potential advantages (or a pointer to a place where
> they are listed) ?

Here are some of them.

1. No need to list every source file in scripts, since one can use globbing.*
2. Build scripts are written in Python and can use the full power of a
general programming language. This is immensely important once you
start to do non-standard things during the build.
3. On Windows it does not require emulation layers or shell
replacements like Cygwin or MSYS.
4. Good support for parallel builds, even when the sources and build
scripts are in multiple directories.
5. Can replace the current btool + automake combo, so we finally have
one build system for all platforms. (This is actually the main
reason.)
6. It takes about 100 kB, so it can be bundled with the source
tarball. We can ship a version tweaked to our liking, for example
without tool modules we don't use or with extra features. (That's what
I do now, I use r6828 of waf-1.6 branch, though perhaps I could tweak
the scripts to work with waf 1.5)
7. It is easy to include generated .cpp code as the source of an
executable or library (once you figure out the correct way - the docs
are useless).
8. Everything created by the build system is kept in the "build"
directory (the name can be changed), so distclean is as simple as
deleting "build".

There are also some downsides.

1. I do not understand the maintainer's development philosophy. For
example I refactored a portion of the function job_count() that
retrieved the number of CPUs into a new function cpu_count(). He
merged it back into job_count() and added a somewhat arbitrary limit
of 1024 simultaneous jobs. Then there was an "ordered dictionary" that
stored the insertion order in a list. When adding a key, it searched
the list rather than the dictionary to see whether the key exists. He
declined to change it to search in the dictionary, because it was an
"unnecessary optimization". He also said that "the list will never
reach 1000 elements".
2. Since the maintainer started working on the waf-1.6 branch, he does
not keep it in a working state, but rather uses the SVN repository
like remote storage for his experiments. Not to mention the fact that
he uses the trunk for the stable version and the waf-1.6 branch for
new development.
3. The API docs are non-existent. The only existing piece of
documentation, the "Waf book", is in large part irrelevant to the end
user and non-free (CC with no derivative works clause). When asked
about why it's non-free and others can't improve it, the maintainer
said it's to prevent distributions from shipping a system-wide Waf
package, which is discouraged. This reason is bogus because there is a
Waf package in Debian that simply doesn't include the non-free book.
4. Certain parts of the code rely on Python-specific tricks like
replacing methods in classes or compiling code at runtime, which makes
it very hard to see what's going on and is often unnecessary, because
the same functionality can be obtained using more traditional
techniques.
5. Support for multiple configurations (like VPATH builds in
Autotools) is incomplete.
6. Checking for headers is sometimes annoying, because the check
methods do not return True/False.

To sum up, Waf is similar in principle to SCons (scripts are Python),
but its different architecture allows it to be faster. However, its
code isn't great, it's mostly undocumented, and the maintainer isn't
easy to work with. The best that could happen is if someone forked
Waf, refactored and documented it. But this might not be realistic. I
think Waf 1.5 is still less pain to use than Autotools.

*) I read somewhere that having to spell out every source file in
Autotools was originally a design decision. The rationale for this is
dubious ("people would forget to add files to source control") and
makes it easy to keep dead code in the tree.

Regards, Krzysztof

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Waf build branch

Bugzilla from verbalshadow@gmail.com
> 1. No need to list every source file in scripts, since one can use
>  globbing.* 2. Build scripts are written in Python and can use the full
>  power of a general programming language. This is immensely important once
>  you start to do non-standard things during the build.

Globbing while easy is not the correct way to do IMO. Globbing means the that
build system has no way of knowing if new files have appeared unless you rerun
the build system again. Unless waf has some magic I'm not aware of.
Their more be more issues with recursive make but I haven't done a lot of
looking.

> 3. On Windows it does not require emulation layers or shell
> replacements like Cygwin or MSYS.

Neither does the build system that I was working on.

> 4. Good support for parallel builds, even when the sources and build
> scripts are in multiple directories.

Cmake provides this.

> 5. Can replace the current btool + automake combo, so we finally have
> one build system for all platforms. (This is actually the main
> reason.)

Agreed this is a great goal. Though I have not been working on the Cmake build
lately it is my goal as well.

> 6. It takes about 100 kB, so it can be bundled with the source
> tarball.

It is a moot point. All the build system scripts are in BZR.

You still have to install python. While it is likely that any *nix platform
will have python installed by default is much higher than than any Windows or
OSX systems. It is not 100% a crossed the board. Setting up a build
environment some work is going to have to happen. It does not matter which
build system script you use some prerequisites to function have to be
installed.

> 7. It is easy to include generated .cpp code as the source of an
> executable or library (once you figure out the correct way - the docs
> are useless).

Bad Documents that sounds like one of the reasons you want not use cmake.
Cmake documention is ok and has a larger community of people to help.

> 8. Everything created by the build system is kept in the "build"
> directory (the name can be changed), so distclean is as simple as
> deleting "build".
>

This can be done in autotools and cmake. Not as common in autotool builds but
it works even with inkscape's current scripts (last time in checked). Out of
source builds on the other hand is cmake's bread and butter.




Joshua L. Blocher
verbalshadow

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Waf build branch

Krzysztof Kosiński
2010/1/9 Joshua L. Blocher <[hidden email]>:

>> 1. No need to list every source file in scripts, since one can use
>>  globbing.* 2. Build scripts are written in Python and can use the full
>>  power of a general programming language. This is immensely important once
>>  you start to do non-standard things during the build.
>
> Globbing while easy is not the correct way to do IMO. Globbing means the that
> build system has no way of knowing if new files have appeared unless you rerun
> the build system again. Unless waf has some magic I'm not aware of.
> Their more be more issues with recursive make but I haven't done a lot of
> looking.

Waf has zero issues with recursive scripts (because the compilation is
run after all user scripts complete) and zero issues with globbing. If
I make a new file, Waf detects it, compiles the new file and relinks
the executable, without any need to modify wscripts. That's because
the dependency tracking is done at a different level than Make, I
can't explain it in detail now, but it obviously works.

>> 7. It is easy to include generated .cpp code as the source of an
>> executable or library (once you figure out the correct way - the docs
>> are useless).
>
> Bad Documents that sounds like one of the reasons you want not use cmake.
> Cmake documention is ok and has a larger community of people to help.

The reason I don't want to use CMake is that its syntax is weak and
it's verbose when doing anything complicated. For example the "if"
construct is annoyingly weak. In Python I can just write: sources +=
['file1.cpp', 'file2.cpp'], while in CMake I would have to write, if I
remember correctly, SET(sources ${sources} file1.cpp file2.cpp).
Complicated build systems are most efficiently expressed in general
purpose programming languages.

The docs situation in Waf can be improved by adding Epydoc comments to
the source. The API itself is sound, except a few quirks that can be
fixed locally

>> 8. Everything created by the build system is kept in the "build"
>> directory (the name can be changed), so distclean is as simple as
>> deleting "build".
>
> This can be done in autotools and cmake. Not as common in autotool builds but
> it works even with inkscape's current scripts (last time in checked). Out of
> source builds on the other hand is cmake's bread and butter.

Autotools can't do this because it leaves droppings in the main source
dir (e.g. config.guess and aclocal.m4), and Automake creates .in files
in the source tree. Didn't check how CMake behaves.

Regards, Krzysztof

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Waf build branch

Michal Suchanek-2
In reply to this post by Krzysztof Kosiński
2010/1/8 Krzysztof Kosiński <[hidden email]>:
OK, it looks like you put some thought into choosing the system and
it's really a tradeoff between features.
>
> To sum up, Waf is similar in principle to SCons (scripts are Python),
> but its different architecture allows it to be faster. However, its
> code isn't great, it's mostly undocumented, and the maintainer isn't
> easy to work with. The best that could happen is if someone forked
> Waf, refactored and documented it. But this might not be realistic. I
> think Waf 1.5 is still less pain to use than Autotools.

As the merits and demerits were mostly discussed already I would like
to point out that lack of design, documentation and maintainer
cooperation are exactly the things I hate about software, any
software.

I saw only one other project using waf and I had a problem building
it. The waf scripts did not produce any error messages whatsoever when
a test failed so I had to look at the sources and run the command
manually to see how it is failing.

I reported it to the maintainer of the project who said that waf has
no facilities for reporting errors so I should report it to waf
maintainer. As I am not a waf user myself I was somewhat reluctant but
found that there is a waf issue already reported about that resolved
as wontfix. As the project author thinks that adding error reporting
to every test is too much work there will be likely no error reporting
for that project, ever. Perhaps it should be done in a separate module
which is used by the tests, who knows. Lack of documentation ..

That's not to say that waf cannot be used effectively, especially if
one is committed to customizing it when it is lacking in some areas.
Using customized version of a piece of software tends to be somewhat
problematic but every build system seems to come with its own
problems.

Thanks

Michal

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Waf build branch

Krzysztof Kosiński
W dniu 9 stycznia 2010 02:36 użytkownik Michal Suchanek
<[hidden email]> napisał:
> 2010/1/8 Krzysztof Kosiński <[hidden email]>:
> As the merits and demerits were mostly discussed already I would like
> to point out that lack of design, documentation and maintainer
> cooperation are exactly the things I hate about software, any
> software.

The design of Waf is actually its strongest point. It's the
implementation that's sometimes lacking, but the same could be said
about Inkscape. :) Waf's total source size is only about 200kB
(roughly the same as toolbox.cpp), so even extensive modifications are
not out of the question.

Regards, Krzysztof

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Waf build branch

J.B.C.Engelen
I have not tried the Waf build branch yet; but Josh and I have started to work on building Inkscape with CMake again, here: lp:~inkscape.dev/inkscape/cmake-build.
Back in the day, I recall we almost had it working, but right now it's not working on Windows (don't know about Linux). Of course, any help is welcome.

Ciao,
  Johan

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Waf build branch

Krzysztof Kosiński
W dniu 19 stycznia 2010 09:28 użytkownik
<[hidden email]> napisał:
> I have not tried the Waf build branch yet; but Josh and I have started to work on building Inkscape with CMake again, here: lp:~inkscape.dev/inkscape/cmake-build.
> Back in the day, I recall we almost had it working, but right now it's not working on Windows (don't know about Linux). Of course, any help is welcome.

It's also not working on Linux (and never was). The main problem is
that it tries to put all files beginning with "sp" in a static
library, and this causes circular dependencies between "libsp" and the
rest of files.

The Waf branch currently configures and builds on both Windows and
Linux. It should work on Mac OS X with some tweaking, but I don't have
any OS X system at hand to test it. It installs correctly on Linux
(though I didn't check it extensively), handles updating the
translation templates (./waf i18n), and shows the Bazaar revision
number and branch name in the About dialog. On Windows it requires a
system-wide installation of Python 2.6 to work (which is different
from the Python in devlibs, but it doesn't cause any issues, at least
during the build). I added some environment magic so that the only
variable you need to set before building is DEVLIBS_PATH. Finally, the
code is Python, so I think many people will understand most of it
without needing to learn the CMake language.

Currently I'm working on porting the "dist" command from btool (last
piece of the Windows puzzle) and the cxxtest stuff.

Regards, Krzysztof

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Waf build branch

Krzysztof Kosiński
Now the waf-build branch supports the following:
- Compiles on Linux and Windows
- CxxTest works on Linux and Windows (using "waf check")
- Creating a Windows distribution directory (like "btool dist-all")
using "waf windows_dist"
- Compiling NSIS installer using "waf nsis"
- Two-part executables (debug symbols in separate file) on both platforms

Regards, Krzysztof

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Waf build branch

Krzysztof Kosiński
W dniu 25 stycznia 2010 04:42 użytkownik the Adib
<[hidden email]> napisał:
> Krzysztof,
>
> does it build parallel (aka make -j2)?
>
> Thx, Adib.

Yes. If you don't give it any parameters it will use all available
logical CPUs. I use it on an i7 (8 cores) and in a Windows VM with 2
cores without any issues.

I'll put detailed instructions on how to build on Windows using
devlibs and the waf-build branch on the wiki, hopefully today or
tommorow.

Regards, Krzysztof

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Loading...