On Monday, 12 August 2013 at 16:29:36 UTC, H. S. Teoh wrote:
> What do you say? Let's throw together an SConstruct for DMD, druntime,and phobos, and submit a pull for it?

I don't care as long as you're willing to maintain whatever you choose.  But SCons?  Granted it's been a few years since I deigned to look at it, but it's historically caused a lot of packaging headaches.

> The only downside is that I can predict people will start complaining
> about the Python dependency. (Which is why I proposed writing a build
> system in D -- it will be superior to make (anything would be!), and
> people will have no excuse about what language it's written in.)
>
Do you plan on bundling it or are you expecting people to install it?  Does it properly handle library search yet or is it still using naive name-only lookup? How about environment variables like CC and PATH?  Has it become resilient against python version changes completely breaking it?  etc.

Despite how onerous they are, Autotools and CMake have a better track record that I've seen.

-Wyatt

On Mon, 2013-08-12 at 19:48 +0200, Wyatt wrote:
[…]
> I don't care as long as you're willing to maintain whatever you choose.  But SCons?  Granted it's been a few years since I deigned to look at it, but it's historically caused a lot of packaging headaches.

And Make hasn't ;-)

[…]
> Do you plan on bundling it or are you expecting people to install it?  Does it properly handle library search yet or is it still using naive name-only lookup? How about environment variables like CC and PATH?  Has it become resilient against python version changes completely breaking it?  etc.

This is where Waf has a benefit. SCons can put the build system with the project leaving only a Python dependency, but Waf is built for this mode of working.

> Despite how onerous they are, Autotools and CMake have a better track record that I've seen.

The QtD CMake reminds me of why I gave up on CMake and switched whole heartedly to SCons (and sometimes Waf) for native code builds.

Autotools was a magnificent piece of macro hacking over Make, but CMake is better. It's just that compared to SCons, at least for me, CMake is fourth division.

SCons is not perfect, it has many problem. The biggest of which is no resource for development.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Aug 10, 2013, at 11:46 PM, Mike Parker <aldacron@gmail.com> wrote:

> Things can be wonky from a vanilla windows command prompt, which is why I never use any Linux tools there. MSYS makes all those problems go away. I use git exclusively on windows, but via gitbash, which is built on top of MSYS.
> 
> Of course, it would be silly to require MSYS or Cygwin to build on Windows, but there's always CMake. A number of open source projects use it these days. Ship a configuration file with the source, then the user can generate Makefiles for a number of compilers and platforms.

I haven't used it recently, but GnuWin32 (http://gnuwin32.sourceforge.net/) provides good ports of *nix apps without the need for MSYS or Cygwin.

On Aug 11, 2013, at 1:36 PM, Walter Bright <newshound2@digitalmars.com> wrote:

> On the subject of friction, I believe we make a mistake by making a dependency on libcurl, a library over which we don't have control.

Absolutely.  As much as I like libcurl, I was kind of surprised when it was bundled with DMD.

On Aug 11, 2013, at 2:46 PM, Walter Bright <newshound2@digitalmars.com> wrote:

> Oh, I forgot to mention, licensing.
> 
> We want Phobos to be free of any restrictive licensing. GPL is restrictive, and so is LGPL.

Yep.  And while LGPL is theoretically fine in most situations, a lot of legal teams still run screaming from any license containing "GPL" regardless of the actual content.  The Boost license is the most practical choice for allowing the most people to use our code without restriction.

On Aug 11, 2013, at 3:18 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Sunday, August 11, 2013 14:43:13 Walter Bright wrote:
>> That said, as soon as the D *package* starts to depend on non-default-installed libraries, trouble happens. With libcurl, the only solution so far seems to be to BUILD OUR OWN LIBCURL binary!
> 
> At this point, I'm inclined to think that while it's great for us to have bindings to C libraries and to have user-friendly, D wrappers around them, it's better that they don't end up in Phobos.

Once D has a good, well-known package system I think the inclination to make Phobos a "kitchen sink" library may subside somewhat.

On 8/12/13 11:06 AM, Russel Winder wrote:
> SCons is not perfect, it has many problem. The biggest of which is no
> resource for development.

I'm hanging a general comment here for a lack of a better place.

We're far from being enamored to make and we have no vested interest in keeping it. At the same time its place in the dmd foodchain is relatively modest (i.e. it's not a big hindrance to most developers) and replacing it with even the perfect tool is unlikely to make our lives significantly better. Worse, there seems to be no obvious replacement for make - each seems to comes with its own issues as you exemplify above for SCons - which further undermines motivation.

Yes, there is duplication across posix.mak and winxx.mak. Inside winxx.mak there is yet another level of annoying duplication. But we don't work on those files frequently enough for all that to be a large problem. That being said, yes, I wish that all got improved. But the margins involved are small enough to make it difficult for the solution to become worse than the problem.


Andrei

On 8/12/13 11:08 AM, Sean Kelly wrote:
> On Aug 11, 2013, at 1:36 PM, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> On the subject of friction, I believe we make a mistake by making a
>> dependency on libcurl, a library over which we don't have control.
>
> Absolutely.  As much as I like libcurl, I was kind of surprised when
> it was bundled with DMD.

On the other hand we instantly got a library that took years in development and testing, that a lot of people are familiar with. C'mon people do I need to spell it out that it's always tradeoffs as opposed to only goods or only bads?

Andrei

On 8/12/2013 11:13 AM, Andrei Alexandrescu wrote:
> I'm hanging a general comment here for a lack of a better place.
>
> We're far from being enamored to make and we have no vested interest in keeping
> it. At the same time its place in the dmd foodchain is relatively modest (i.e.
> it's not a big hindrance to most developers) and replacing it with even the
> perfect tool is unlikely to make our lives significantly better. Worse, there
> seems to be no obvious replacement for make - each seems to comes with its own
> issues as you exemplify above for SCons - which further undermines motivation.
>
> Yes, there is duplication across posix.mak and winxx.mak. Inside winxx.mak there
> is yet another level of annoying duplication. But we don't work on those files
> frequently enough for all that to be a large problem. That being said, yes, I
> wish that all got improved. But the margins involved are small enough to make it
> difficult for the solution to become worse than the problem.

Exactly. There's a matter of proportion. We don't need to use a cannon (and all the support a cannon needs) to kill a cockroach.

For example: building in a Python dependency just so a user can compile dmd? This is seriously out of place, besides a giant WTF telling anyone who wants to install dmd on Windows that he has to go find Python and install that, too?

On Aug 12, 2013, at 11:26 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 8/12/13 11:08 AM, Sean Kelly wrote:
>> On Aug 11, 2013, at 1:36 PM, Walter Bright <newshound2@digitalmars.com> wrote:
>> 
>>> On the subject of friction, I believe we make a mistake by making a dependency on libcurl, a library over which we don't have control.
>> 
>> Absolutely.  As much as I like libcurl, I was kind of surprised when it was bundled with DMD.
> 
> On the other hand we instantly got a library that took years in development and testing, that a lot of people are familiar with. C'mon people do I need to spell it out that it's always tradeoffs as opposed to only goods or only bads?

I don't think anyone was suggesting otherwise.