On 05/04/12 18:16, Alex Rønne Petersen wrote:
> In that case, that doesn't stop Waf though - your Waf build script is just in
> plain source form while Waf itself (which runs the script) is in compressed form.

But it does, for exactly the reasons I outlined.  GPL-wise, that zipped-up part would be considered part of the build script -- after all, it's included in it, and so covered by the GPL provisions.

It would be different if it was an entirely independent package separately installed on the system, but as we already discussed, Waf is not designed to be used that way.

On 05-04-2012 20:31, Joseph Rushton Wakeling wrote:
> On 05/04/12 18:16, Alex Rønne Petersen wrote:
>> In that case, that doesn't stop Waf though - your Waf build script is
>> just in
>> plain source form while Waf itself (which runs the script) is in
>> compressed form.
>
> But it does, for exactly the reasons I outlined. GPL-wise, that
> zipped-up part would be considered part of the build script -- after
> all, it's included in it, and so covered by the GPL provisions.

*Confused*. The way I see it, this situation is exactly equivalent to having a readily-available Autotools script that relies on a proprietary Autotools?

>
> It would be different if it was an entirely independent package
> separately installed on the system, but as we already discussed, Waf is
> not designed to be used that way.

I don't quite understand this, though. The fact that Waf sits in a source control repository shouldn't really matter at all. It could as well sit anywhere on your system; it just isn't designed for that.

Is the problem here that the GPL considers Waf part of this whole thing because you generally ship the Waf binary in source distributions of your software?

-- 
- Alex

On 05/04/12 20:56, Alex Rønne Petersen wrote:
> *Confused*. The way I see it, this situation is exactly equivalent to having a
> readily-available Autotools script that relies on a proprietary Autotools?

No, because it's _contained within_ the build script.  Everything within the build script has to comply with the license terms.

> I don't quite understand this, though. The fact that Waf sits in a source
> control repository shouldn't really matter at all. It could as well sit anywhere
> on your system; it just isn't designed for that.
>
> Is the problem here that the GPL considers Waf part of this whole thing because
> you generally ship the Waf binary in source distributions of your software?

I think that's about it.  It's contained in the build script, so it's considered part of the build script; and therefore subject to the same terms and conditions.

By comparison, a Makefile doesn't _contain_ make; make is a separate piece of software that's used to _interpret_ the Makefile.

On 05-04-2012 23:30, Joseph Rushton Wakeling wrote:
> On 05/04/12 20:56, Alex Rønne Petersen wrote:
>> *Confused*. The way I see it, this situation is exactly equivalent to
>> having a
>> readily-available Autotools script that relies on a proprietary
>> Autotools?
>
> No, because it's _contained within_ the build script. Everything within
> the build script has to comply with the license terms.
>
>> I don't quite understand this, though. The fact that Waf sits in a source
>> control repository shouldn't really matter at all. It could as well
>> sit anywhere
>> on your system; it just isn't designed for that.
>>
>> Is the problem here that the GPL considers Waf part of this whole
>> thing because
>> you generally ship the Waf binary in source distributions of your
>> software?
>
> I think that's about it. It's contained in the build script, so it's
> considered part of the build script; and therefore subject to the same
> terms and conditions.
>
> By comparison, a Makefile doesn't _contain_ make; make is a separate
> piece of software that's used to _interpret_ the Makefile.

OK, I understand what you're saying, but I think there's a misunderstanding here: With Waf, you *do* write a build script like you do with e.g. Make, and this so-called wscript sits outside Waf. See for example: https://github.com/lycus/mci/blob/master/wscript

The Waf binary loads up this script and executes it when you issue build commands, much like Make does for Makefiles.

-- 
- Alex

Joseph Rushton Wakeling, el  5 de abril a las 17:42 me escribiste:
> On 05/04/12 13:16, Leandro Lucarella wrote:
> >Joseph Rushton Wakeling, el  4 de abril a las 15:43 me escribiste:
> >>To see why it matters, imagine a corporate entity releasing a large, complex piece of software where the code was under a free licence but the build system was proprietary and internal to the company. It'd be a major block to practically enjoying the licence freedoms.
> >
> >This is new to GPLv3 right? Because several companies are already doing this, specially companies selling small devices with Linux, usually they
> 
> No, it's also in GPLv2, but in Section 3, with slightly different language:
> 
>   The source code for a work means the preferred form of the work for making
>   modifications to it. For an executable work, complete source code means all
>   the source code for all modules it contains, plus any associated interface
>   definition files, plus the scripts used to control compilation and
>   installation of the executable.
> 
> [... see https://www.gnu.org/licenses/gpl-2.0.html ...]

Mmm, I wonder if Edimax and WesternDigital are violating the GPL then... Maybe they provide some convoluted script or way to build it but as far as I recall it wasn't easy at all to use the source code they provide.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Spooker3 always wanted to learn russian...but learned C++ instead :)

On 06/04/12 08:11, Alex Rønne Petersen wrote:
> OK, I understand what you're saying, but I think there's a misunderstanding
> here: With Waf, you *do* write a build script like you do with e.g. Make, and
> this so-called wscript sits outside Waf. See for example:
> https://github.com/lycus/mci/blob/master/wscript
>
> The Waf binary loads up this script and executes it when you issue build
> commands, much like Make does for Makefiles.

Yes, but -- if I understand correctly -- the Waf binary is provided as an integral part of the source distribution.  It's not just another program that sits elsewhere on your computer and can be installed independently.

In fact, the zipped-up wscript is contained within the build script as a binary blob, no?  This alone is enough to make it fall under the GPL provisions.

Joseph Rushton Wakeling, el  6 de abril a las 15:00 me escribiste:
> On 06/04/12 08:11, Alex Rønne Petersen wrote:
> >OK, I understand what you're saying, but I think there's a misunderstanding here: With Waf, you *do* write a build script like you do with e.g. Make, and this so-called wscript sits outside Waf. See for example: https://github.com/lycus/mci/blob/master/wscript
> >
> >The Waf binary loads up this script and executes it when you issue build commands, much like Make does for Makefiles.
> 
> Yes, but -- if I understand correctly -- the Waf binary is provided as an integral part of the source distribution.  It's not just another program that sits elsewhere on your computer and can be installed independently.
> 
> In fact, the zipped-up wscript is contained within the build script as a binary blob, no?  This alone is enough to make it fall under the GPL provisions.

No IIRC.  You can download and use the waf binary from wherever you like and the script you write has nothing to do with the binary. The binary just run the script as someone told you before. The only catch is that thing about changing the API, so you'll have to download the exact version used by the upstream author (or one that still works for that script)

Think as if someone just shipped a make binary with their software, the makefile is still a script independent with the make binary and you can use another make binary to run it.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
El otro día tenía un plan
Pero después me olvidé y me comí un flan

On 4/6/2012 8:00 AM, Joseph Rushton Wakeling wrote:
> In fact, the zipped-up wscript is contained within the build script as a
> binary blob, no? This alone is enough to make it fall under the GPL
> provisions.

An interesting thing to note about the waf binary blob.  Currently, it actually extracts it's entire source into a cache directory.

On the first run, you'll find a directory like waf3-1.6.10-84fbc87adc22fe809febcc192afd90b1 inside which is the full obfuscated code for Waf.  The important thing is that this code *can* be modified and changes will persist until you decide to wipe them.

I've been too lazy to upgrade to newer releases due to api issues, so I'll often apply patches to the cache to fix minor issues I have.

At this point, the waf binary should be considered no different than a zip file containing source.  It's just that this fact isn't obvious.

On 03/04/2012 22:11, Jacob Carlborg wrote:
> On 2012-04-03 22:36, Robert Clipsham wrote:
>> So use D! I use D for my build script, works just fine.
>>
>> https://github.com/mrmonday/serenity/blob/master/build.d
>>
>> In ~365 LoC that I hacked together and didn't put much effort in to it
>> builds a library and a binary, prints a coloured status update, supports
>> parallel and remote builds, debug and release builds and a few other
>> things.
>>
>> Bonuses:
>> * You get a full, awesome language to use
>> * It's fast and easy
>> * It's very maintainable by anyone who's working on your code (since
>> they already know D)
>>
>
> But that only works for Posix?
>

Works fine on Windows too, just give your build instructions as:

rdmd build.d

Rather than ./build.d. Providing there is a working D installation in your PATH it'll work just fine.

-- 
Robert
http://octarineparrot.com/

On 04/04/12 12:54, Iain Buclaw wrote:
> There's actually more than one side of the argument here other than
> the one you raise, that are creeping up recurring topics alley.
>
> On the note of integration into the FOSS ecosystem, I'm firing off
> technical review of gdc for inclusion sometime later today.

Since it may be useful, I thought I'd make a handful of notes on the issues I've faced, as a fairly committed (but not fundamentalist) FOSS user, in getting on with D.

I can't remember exactly when or how I discovered D; I think it was probably some time in late 2007 or through 2008.  I was something of a novice in C++ at this point (I'd always worked in C) and was very attracted by the C++-like but clearly much more attractive and effective syntax and design.

The major concerns I had in using D covered a range of practical, technical and ethical issues.  Some of what I say here may come down to not having read up on the latest D progress -- my apologies in advance for any unfair critiques.


** Availability of D support for mainstream Linux distros **

This actually covered two different concerns: one was the packaging and ease of availability of DMD for different mainstream Linux distros; the second was FOSS compiler support and development roadmaps.

Packaging was a requirement not just for my own convenience but as an indicator of how easily I could get other people involved in contributing to any project I might start.  Even if I could handle a more complicated install, I didn't want anyone else to have to.

FOSS compiler support was for me a long-term requirement but not an immediate short-term one; I'd have happily used DMD as a stopgap so long as there was a clear sign of strong development activity on an up-to-date FOSS compiler to be arriving in the near future.  At the time I was first engaged with D, this really didn't seem to be the case; GDC seemed to have been abandoned and had only D1 support, LDC was being maintained but didn't seem to have any commitment to work on D2.

This concern has been substantially resolved by the new GDC team's excellent work -- I have to thank Vincenzo Ampolo / Goshawk for the blog updates that kept my interest in place.  The clear statements of intention and support from Walter Bright on getting GDC accepted into the core GNU Compiler Collection were also extremely important.

I made a deliberate choice to avoid attempting to use GDC until the new D2-supporting version was properly packaged and available, something which was partially resolved with Ubuntu 11.10 and is now fully resolved with Ubuntu 12.04.  I don't know to what extent GDC is available in distros beyond Ubuntu and Debian, mainly because my Linux use is been pretty myopic in this respect ;-)

AFAICS the LDC version in Ubuntu 12.04 remains one with only D1 support; it would be good to see activity here, as a broader range of FOSS options both reflects the health of the D community and ensures there are multiple options available in the event that support for one project falters.

It's always been a concern that mainstream development support for D did not seem to be centred around a FOSS reference implementation.  Beyond the ethical aspects is a practical concern -- virtually all of the widely-adopted new languages of the last 10-20 years seem to have been built around FOSS.


** Performance of D code **

Most of my coding is for number-crunching simulations.  The last time I tried working with D, I found that DMD-compiled code was running at about half the speed of equivalent C++.  IIRC this was suggested to be because DMD's floating-point operations were not optimized to the same degree as g++.

A couple of casual tests in the last days with the same codebases suggest that GDC produces code of comparable speed to g++.  Which is nice. :-)

I'll be keeping an eye on this, obviously, but it looks like it may have been resolved for GDC at least.  I have a memory that the earlier gdc2 package in Ubuntu 11.10 built code that still ran a fair bit slower -- were any floating-point or other speed optimizations brought in recently?


** Easy use of C or C++ libraries and other languages **

As a relatively new language D was not as well-supplied with library packages compared to those I was used to using with C/C++ (or, where supplied, these were not incorporated into Linux distros).  At first glance at the documentation, it looked like this might not be an issue as it ought to be possible to use existing C and maybe C++ libraries.

I was keen on using D with the GNU Scientific Library (GSL), but found this impossible to do -- it turned out that the process of putting in place D bindings for the library was incredibly complicated and in-depth.  I'm sure this was partially inexperience and lack of understanding of what was necessary, but it was very offputting given that the documentation stressed that D worked well in combination with C.

It wasn't clear to me whether I needed to construct full bindings for the library or whether I could do this for the minimal set of library functions that I was calling.  In the event I never tried because (i) I wanted to build full GDC bindings anyway and (ii) the D/C++ speed differences mentioned above made it feel not worthwhile to keep pushing with D for the specific project I was engaged in, even if I could have limited my hooks to a handful of GSL functions.

Obviously the optimal situation would be for D to interface seamlessly with C/C++ libraries without the developer having to do anything on a per-library basis; I have no idea of the extent to which that's feasible.  What is still a concern is the lack of D libraries or bindings to popular libraries in C/C++ and other languages, available as packages in mainstream Linux distros (e.g. QtD, similar support for GTK+, Boost, ...).

The general case here is of course getting D to hook into different languages and I'm not sure of what the possibilities are.  IIRC Swig offers support for D, but as I didn't have a very nice time hooking together C++ and Python using Swig, I'd welcome simpler options.


** Summary **

D being a language with limited adoption, my main concerns in using it were the extent to which it would be easy to (i) get other people involved in a D-based project; (ii) avoid reinventing or rewriting the wheel in terms of 3rd-party libraries; and (iii) have performance comparable to that I could already get with C/C++.

What that means in practice is having at least 1 well-supported FOSS compiler, together with a broad collection of library functionality, either via dedicated D libraries or bindings to libraries in other languages.  All of this needs to be packaged for mainstream Linux distros.

This is partly a matter of me being lazy (I want to _use_ the language, not deal with setup problems) but also a matter of being confident it's a language that will be easy for others to adopt.  This is why e.g. even though I'm unlikely to write GUI applications, I'd like to see Qt/GTK+ support packaged, because I know that plenty of other people _will_ want that kind of support in place.

Anyway, all this has gone on for a fair length of time, so I think I'll stop here -- hope it was all useful info.

Thanks and best wishes,

    -- Joe