View mode: basic / threaded / horizontal-split · Log in · Help
April 05, 2012
Re: Compiling with gdc vs. gdmd
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.
April 05, 2012
Re: Compiling with gdc vs. gdmd
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
April 05, 2012
Re: Compiling with gdc vs. gdmd
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.
April 06, 2012
Re: Compiling with gdc vs. gdmd
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
April 06, 2012
Re: Compiling with gdc vs. gdmd
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 :)
April 06, 2012
Re: Compiling with gdc vs. gdmd
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.
April 06, 2012
Re: Compiling with gdc vs. gdmd
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
April 07, 2012
Re: Compiling with gdc vs. gdmd
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.
April 07, 2012
Re: Compiling with gdc vs. gdmd
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/
April 08, 2012
D and the FOSS ecosystem
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
1 2 3 4 5
Top | Discussion index | About this forum | D home