Jacob Carlborg, el  3 de abril a las 19:38 me escribiste:
> >Make is only a small part of the picture, is just a dependency tracking program, and a pretty good one if you ask me (but I agree it could be better), to work you have to specify the dependencies (manually or automatically, it's up to you). I don't know Rake but I would be very surprised if it's really better than Make at doing what Make was designed for. *Very surprised*.
> 
> Ok, let me rephrase that. Rakefiles have a lot better syntax than makefiles.

Fair enough. But I guess that's just personal taste, I really like Make
syntax better (the only thing that annoys me is $(variables) and
$(function call) syntax, that could be definitely better).

But to me this:
file "prog" => ["a.o", "b.o"] do |t|
  sh "cc -o #{t.name} #{t.prerequisites.join(' ')}"
end

Looks much complicated (and with way much more syntax overhead) than
this:
prog: a.o b.o
	cc -o $@ $^

BTW, I took a look at Rake and it lacks a lot of Make features (well GMake at least, I usually stick to GMake because it's usually available anywhere), just for the command-line: --jobs (!), --question, --what-if, --always-make, --keep-going. Also I didn't see anything about the secondary expansion, rebuilding the Makefile itself, target-specific variables, implicit rules, pattern rules with multiple targets, .... Also for me using a declarative language instead of a imperative one is a better choice for this kind of applications.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
aFR [afr@my.farts.cause.nuclear.reaction.org] has quit IRC (Ping timeout)

On 2012-04-04 10:19, Leandro Lucarella wrote:
> Fair enough. But I guess that's just personal taste, I really like Make
> syntax better (the only thing that annoys me is $(variables) and
> $(function call) syntax, that could be definitely better).
>
> But to me this:
> file "prog" =>  ["a.o", "b.o"] do |t|
>    sh "cc -o #{t.name} #{t.prerequisites.join(' ')}"
> end
>
> Looks much complicated (and with way much more syntax overhead) than
> this:
> prog: a.o b.o
> 	cc -o $@ $^

Sure, I guess makefiles both have their pros and cons. One of the advantage is that you can invoke shell commands. This is at the same time a disadvantage, that makes the language syntax complicated. In my opinion it's just too many symbols.

When you need to do more complicate stuff that requires if-statements and functions then I think Ruby is superior.

But it might be as I've said, too many people uses Make as a build system and not a tracking system.

> BTW, I took a look at Rake and it lacks a lot of Make features (well
> GMake at least, I usually stick to GMake because it's usually available
> anywhere), just for the command-line: --jobs (!), --question, --what-if,
> --always-make, --keep-going. Also I didn't see anything about the
> secondary expansion, rebuilding the Makefile itself, target-specific
> variables, implicit rules, pattern rules with multiple targets, ....
> Also for me using a declarative language instead of a imperative one is
> a better choice for this kind of applications.

I've actually never done a direct comparison. It just the feel I've got when I've used the tools.

-- 
/Jacob Carlborg

> What went wrong here is that the Debian guys tried to package something as a
> system-level package when it isn't supposed to be. I don't really see anything
> wrong in the Waf dev trying to prevent this; not doing so is letting Debian
> shoot itself in the foot, only to come back to Waf later and complain, when they
> were already warned.
>
> So, I just think you should reevaluate what you're basing your decision on here. :)

It's not just the packaging issue that's at stake re Debian -- there's also the way in which the developer has played games with non-free licensing (not a good sign IMO), and the fact that the zipped-up code in the waf script contains an obfuscated copy that is not identical to upstream.

In fact, for Debian this was never about the packaging -- they only considered packaging BECAUSE the script included a zipped-up and obfuscated part.  See http://lists.debian.org/debian-devel/2012/02/msg00207.html and in particular the passage reading,

> This means that we are distributing files derived from the waf.git
> source code, but not the waf.git source code itself.  This is of
> course completely unacceptable in Debian.  (It is not a violation of
> the copyright on waf itself as waf has a permissive non-copyleft
> licence; but will be a breach of the copyright on any GPL'd waf-using
> package, because the GPL's requirements extend to the build system.)
>
> I suggest the following fix:
>
>  * Upstream waf should be packaged somehow.

As for me, DFSG compatibility is important, so I'm not happy using a build script that has these issues.  My code would almost certainly be released under GPL or AGPL, so I'd also fall foul of the licensing issues identified.

I don't think it's worth discussing this further -- I don't want to turn the d.gnu list into a big debate on Debian policy or licensing technicalities -- but from a gdc point of view I'd really welcome ideas on alternative build systems that work well with gdc.

(Sorry if this sounds like I'm making trouble for the sake of it.  I'm concerned because to my mind one of the principal problems for D was for a long time the lack of effective free/open source implementations.  I'm keen for D to be well integrated into the FOSS ecosystem, and that means considering other aspects than just the compiler, now solved very well by gdc.)

> (Not sure if you know, but Waf can do all of those.)

That's nice. :-)

On 4 April 2012 11:45, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
>> What went wrong here is that the Debian guys tried to package something as
>> a
>> system-level package when it isn't supposed to be. I don't really see
>> anything
>> wrong in the Waf dev trying to prevent this; not doing so is letting
>> Debian
>> shoot itself in the foot, only to come back to Waf later and complain,
>> when they
>> were already warned.
>>
>> So, I just think you should reevaluate what you're basing your decision on here. :)
>
>
> It's not just the packaging issue that's at stake re Debian -- there's also the way in which the developer has played games with non-free licensing (not a good sign IMO), and the fact that the zipped-up code in the waf script contains an obfuscated copy that is not identical to upstream.
>
> In fact, for Debian this was never about the packaging -- they only considered packaging BECAUSE the script included a zipped-up and obfuscated part.  See http://lists.debian.org/debian-devel/2012/02/msg00207.html and in particular the passage reading,
>
>> This means that we are distributing files derived from the waf.git source code, but not the waf.git source code itself.  This is of course completely unacceptable in Debian.  (It is not a violation of the copyright on waf itself as waf has a permissive non-copyleft licence; but will be a breach of the copyright on any GPL'd waf-using package, because the GPL's requirements extend to the build system.)
>>
>> I suggest the following fix:
>>
>>  * Upstream waf should be packaged somehow.
>
>
> As for me, DFSG compatibility is important, so I'm not happy using a build script that has these issues.  My code would almost certainly be released under GPL or AGPL, so I'd also fall foul of the licensing issues identified.
>
> I don't think it's worth discussing this further -- I don't want to turn the d.gnu list into a big debate on Debian policy or licensing technicalities -- but from a gdc point of view I'd really welcome ideas on alternative build systems that work well with gdc.
>

That's fine, debate away! It's a nice change than it being quiet in here. :~)


> (Sorry if this sounds like I'm making trouble for the sake of it.  I'm concerned because to my mind one of the principal problems for D was for a long time the lack of effective free/open source implementations.  I'm keen for D to be well integrated into the FOSS ecosystem, and that means considering other aspects than just the compiler, now solved very well by gdc.)
>

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.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 04-04-2012 12:45, Joseph Rushton Wakeling wrote:
>> What went wrong here is that the Debian guys tried to package
>> something as a
>> system-level package when it isn't supposed to be. I don't really see
>> anything
>> wrong in the Waf dev trying to prevent this; not doing so is letting
>> Debian
>> shoot itself in the foot, only to come back to Waf later and complain,
>> when they
>> were already warned.
>>
>> So, I just think you should reevaluate what you're basing your
>> decision on here. :)
>
> It's not just the packaging issue that's at stake re Debian -- there's
> also the way in which the developer has played games with non-free
> licensing (not a good sign IMO), and the fact that the zipped-up code in
> the waf script contains an obfuscated copy that is not identical to
> upstream.

It's not obfuscated; the code is just rewritten to be as compact as possible. This is part of Waf's own build process. I'm not sure this is as bad as "obfuscated" makes it sound...

>
> In fact, for Debian this was never about the packaging -- they only
> considered packaging BECAUSE the script included a zipped-up and
> obfuscated part. See
> http://lists.debian.org/debian-devel/2012/02/msg00207.html and in
> particular the passage reading,
>
>> This means that we are distributing files derived from the waf.git
>> source code, but not the waf.git source code itself. This is of
>> course completely unacceptable in Debian. (It is not a violation of
>> the copyright on waf itself as waf has a permissive non-copyleft
>> licence; but will be a breach of the copyright on any GPL'd waf-using
>> package, because the GPL's requirements extend to the build system.)
>>
>> I suggest the following fix:
>>
>> * Upstream waf should be packaged somehow.

GPL extends to the build system? This is news to me... that seems a little overzealous... (or maybe I'm interpreting it incorrectly)

But point taken. If that's how the GPL works, then that's how it is.

>
> As for me, DFSG compatibility is important, so I'm not happy using a
> build script that has these issues. My code would almost certainly be
> released under GPL or AGPL, so I'd also fall foul of the licensing
> issues identified.

I just don't think I'm seeing where the problem arises, since Waf's license is very permissive. But IANAL, etc. ;)

>
> I don't think it's worth discussing this further -- I don't want to turn
> the d.gnu list into a big debate on Debian policy or licensing
> technicalities -- but from a gdc point of view I'd really welcome ideas
> on alternative build systems that work well with gdc.

Oh, don't worry - most discussions on the D newsgroups in general often branch into rather tangential discussions; people don't really mind this at all.

>
> (Sorry if this sounds like I'm making trouble for the sake of it. I'm
> concerned because to my mind one of the principal problems for D was for
> a long time the lack of effective free/open source implementations. I'm
> keen for D to be well integrated into the FOSS ecosystem, and that means
> considering other aspects than just the compiler, now solved very well
> by gdc.)

Not at all. This discussion has been enlightening to me as well.

>
>> (Not sure if you know, but Waf can do all of those.)
>
> That's nice. :-)

All this being said, I don't know of any other good build tool for D (and GDC in particular) at the moment. You may have to resort to using Make and/or Autotools. :/

-- 
- Alex

On 04-04-2012 12:54, Iain Buclaw wrote:
> On 4 April 2012 11:45, Joseph Rushton Wakeling
> <joseph.wakeling@webdrake.net>  wrote:
>>> What went wrong here is that the Debian guys tried to package something as
>>> a
>>> system-level package when it isn't supposed to be. I don't really see
>>> anything
>>> wrong in the Waf dev trying to prevent this; not doing so is letting
>>> Debian
>>> shoot itself in the foot, only to come back to Waf later and complain,
>>> when they
>>> were already warned.
>>>
>>> So, I just think you should reevaluate what you're basing your decision on
>>> here. :)
>>
>>
>> It's not just the packaging issue that's at stake re Debian -- there's also
>> the way in which the developer has played games with non-free licensing (not
>> a good sign IMO), and the fact that the zipped-up code in the waf script
>> contains an obfuscated copy that is not identical to upstream.
>>
>> In fact, for Debian this was never about the packaging -- they only
>> considered packaging BECAUSE the script included a zipped-up and obfuscated
>> part.  See http://lists.debian.org/debian-devel/2012/02/msg00207.html and in
>> particular the passage reading,
>>
>>> This means that we are distributing files derived from the waf.git
>>> source code, but not the waf.git source code itself.  This is of
>>> course completely unacceptable in Debian.  (It is not a violation of
>>> the copyright on waf itself as waf has a permissive non-copyleft
>>> licence; but will be a breach of the copyright on any GPL'd waf-using
>>> package, because the GPL's requirements extend to the build system.)
>>>
>>> I suggest the following fix:
>>>
>>>   * Upstream waf should be packaged somehow.
>>
>>
>> As for me, DFSG compatibility is important, so I'm not happy using a build
>> script that has these issues.  My code would almost certainly be released
>> under GPL or AGPL, so I'd also fall foul of the licensing issues identified.
>>
>> I don't think it's worth discussing this further -- I don't want to turn the
>> d.gnu list into a big debate on Debian policy or licensing technicalities --
>> but from a gdc point of view I'd really welcome ideas on alternative build
>> systems that work well with gdc.
>>
>
> That's fine, debate away! It's a nice change than it being quiet in here. :~)
>
>
>> (Sorry if this sounds like I'm making trouble for the sake of it.  I'm
>> concerned because to my mind one of the principal problems for D was for a
>> long time the lack of effective free/open source implementations.  I'm keen
>> for D to be well integrated into the FOSS ecosystem, and that means
>> considering other aspects than just the compiler, now solved very well by
>> gdc.)
>>
>
> 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.
>

Woo! Great news!

-- 
- Alex

On 04/04/12 14:24, Alex Rønne Petersen wrote:
> GPL extends to the build system? This is news to me... that seems a little
> overzealous... (or maybe I'm interpreting it incorrectly)
>
> But point taken. If that's how the GPL works, then that's how it is.

From Section 1 of the GPL:

   The “Corresponding Source” for a work in object code form means all the
   source code needed to generate, install, and (for an executable work) run
   the object code and to modify the work, including scripts to control those
   activities.

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.

> I just don't think I'm seeing where the problem arises, since Waf's license is
> very permissive. But IANAL, etc. ;)

IANALE, but I think the essential point is that the GPL requires source code to be provided in the appropriate form for editing.  Again from Section 1:

   The “source code” for a work means the preferred form of the work for making
   modifications to it.

The fact that part of the Waf script is zipped up and therefore not immediately available to read might in principle be a violation here -- it's certainly a problem for Debian who view it as imposing an unreasonably hard burden on anyone wishing to tweak the build system e.g. to fix bugs.

However, what really got the Debian guys going is that what's in the zipped file has been processed to remove comments, whitespace etc., so it doesn't actually correspond to the GPL definition of the "source code".  Further, the code is a subset of what's provided in the Waf git repo.

It follows that there is no availability of adequate source code (in the GPL sense of "preferred form for making modifications") corresponding to what's in the Waf script.  So, there is almost certainly a GPL violation if Waf is being distributed as the build script for GPL (or AGPL, or LGPL) licensed software.

It's a shame, because this doesn't seem like a technically insurmountable problem; it's almost certainly down to lack of appreciation of these legal issues on the part of the Waf devs.  That's one reason why I was so concerned over the docs licensing -- it's such an obviously nasty thing to do where FOSS is concerned.

> Oh, don't worry - most discussions on the D newsgroups in general often branch
> into rather tangential discussions; people don't really mind this at all.

Thank you :-)  I'm always conscious about kicking up such discussions as a new and non-contributing party to a product.  Just so long as it is valuable ... :-)

> Not at all. This discussion has been enlightening to me as well.

Excellent. :-)

> All this being said, I don't know of any other good build tool for D (and GDC in
> particular) at the moment. You may have to resort to using Make and/or
> Autotools. :/

I don't mind working with the GNU Autotools at all -- I've used them for other projects -- but I'm concerned about the extent of their support for D.  As you probably know when you're setting up a configure.ac file, you usually call various macros checking e.g. for the presence of the language and corresponding compiler, and so on.  I'm not sure whether the Autotools currently have the macros needed to work with gdc.

I actually looked into this a few years back and exchanged a few emails with the autoconf/automake devs about putting those macros in place, but I quickly realized that the m4 scripting required was beyond me, or at least beyond the practical time commitment I could put in. :-(

Iain Buclaw, el  4 de abril a las 11:54 me escribiste:
> On the note of integration into the FOSS ecosystem, I'm firing off technical review of gdc for inclusion sometime later today.

YEAH! :D

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Pitzulino! Pitzulino!
Todos a cantar por el tubo!
Pitzulino! Pitzulino!
Todos a cantar por el codo!

On 04/04/12 15:43, Joseph Rushton Wakeling wrote:
> 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.

I should probably be more cautious there and say build _script_ rather than build _system_; I'm not sure the GPL legally forbids you releasing a program that builds using (say) a proprietary equivalent of the Autotools, so long as the build script itself is present.

But a non-free build system would almost certainly be a block to inclusion in many of the major Linux distributions.

On 05-04-2012 17:52, Joseph Rushton Wakeling wrote:
> On 04/04/12 15:43, Joseph Rushton Wakeling wrote:
>> 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.
>
> I should probably be more cautious there and say build _script_ rather
> than build _system_; I'm not sure the GPL legally forbids you releasing
> a program that builds using (say) a proprietary equivalent of the
> Autotools, so long as the build script itself is present.

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 a non-free build system would almost certainly be a block to
> inclusion in many of the major Linux distributions.

-- 
- Alex