On Mon, Aug 12, 2013 at 11:08:18AM -0700, 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.

The one saving grace about this situation that it's possible to build Phobos without libcurl, and still get a working toolchain (just that the stuff that uses libcurl wouldn't work).

Or at least, it used to. IIRC with the recent introduction of shared library building for Phobos, this may no longer be true.


T

-- 
To provoke is to call someone stupid; to argue is to call each other stupid.

On Aug 12, 2013, at 11:43 AM, "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Mon, Aug 12, 2013 at 11:08:18AM -0700, 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.
> 
> The one saving grace about this situation that it's possible to build Phobos without libcurl, and still get a working toolchain (just that the stuff that uses libcurl wouldn't work).

Yep.  The current approach still seems kind of confusing though, because to use std.net.curl you have to manually link libcurl, which makes it not feel like an actual part of Phobos.  I'd kind of like to see std.net.curl live entirely within etc.curl to clearly indicate that it's a separate package.  RDMD should automatically link libcurl as well, if it doesn't already (and I can't recall if it does).  I suppose std.zip is in the same boat.

On Mon, Aug 12, 2013 at 11:34:42AM -0700, Walter Bright wrote:
> 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.

But you're missing the bigger picture. What I envision is that this D build tool will go beyond merely building DMD/druntime/Phobos. If it's successful, it can become the *standard* D build tool for all D programs. Having a standard D build tool will go a long way in making D programs portable and easy to install, besides freeing us from a dependency on make.


> 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?

Which is why I proposed writing the build system in D. Ideally, build scripts would themselves be D programs... dogfooding ftw. :)

Objectively speaking, though, this is no different from being required to install make in order to compile dmd. You still have to go out of the way to install a 3rd party program before you can build dmd. The only difference is that make tends to be preinstalled in more systems than python (though nowadays most Linux distros come with python by default, so this factor is becoming much less out of place than you're suggesting).


T

-- 
Curiosity kills the cat. Moral: don't be the cat.

On 8/12/2013 3:48 PM, H. S. Teoh wrote:
> Objectively speaking, though, this is no different from being required
> to install make in order to compile dmd. You still have to go out of the
> way to install a 3rd party program before you can build dmd. The only
> difference is that make tends to be preinstalled in more systems than
> python (though nowadays most Linux distros come with python by default,
> so this factor is becoming much less out of place than you're
> suggesting).



1. Python is not preinstalled on Windows. So then the question is, which Python should the user install? What happens if the user doesn't like that version? What if it conflicts with his other Python he's got installed? What if the Python version is different? What if Python releases an upgrade, and our build system needs to be adjusted to account for that?

2. Make comes with g++. g++ is used to build dmd, so if g++ is installed, so is make.

3. Make doesn't come preinstalled on Windows. But we have a make we can throw in the bin directory without issues. It's only 50K. Nobody goes out of their way - it's there on the same path as dmd. It's always the right version of make to use with our makefiles. We're not going to get into the Python distribution business.

4. Having Python as a prerequisite for using D just paints the wrong image for D.

5. Do we really want D to be restricted to only platforms that have the latest Python up on them?

So no, I do NOT at all regard the issue of requiring Python to be remotely equivalent to requiring Make.

We did have a problem on FreeBSD because the default make on it would not work with posix.mak. gmake had to be explicitly installed. The only saving grace there is that very few people use FreeBSD, and those that do, tend to be pretty handy with installing gmake.

On Mon, 12 Aug 2013 11:06:37 -0700
Sean Kelly <sean@invisibleduck.org> wrote:

> 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.

I can second that. I use GNU's 'grep' and 'tee' from the standard windows command prompt fairly often, and there's some other good stuff in there too. (I've tried other versions of 'tee' for windows, but the GNU one actually seems to be the best. Certainly the fastest by a good margin. There was one made in C# that was dog slow.) I was quite impressed with how well they turned out to work even without Posix and bash.

Perhaps surprisingly though, I don't actually use ls on windows - but
that's only because the win version doesn't give much (any?)
visual distinction of directories vs files. Instead, I stuck an
"ls.bat" in my windows directory that invokes "dir /w %*". Probably my
#1 most used command, aside from maybe cd.

My good experience with some of the GnuWin32 tools is part of what lead me to suggest gmake. But admittedly I haven't actually tried gmake on windows, so there may very well be problems with that one, for all I know.

On Monday, August 12, 2013 15:48:54 H. S. Teoh wrote:
> Which is why I proposed writing the build system in D. Ideally, build scripts would themselves be D programs... dogfooding ftw. :)

I would not want to make any attempt to make dmd, druntime, and Phobos build with a "standard D build tool" until it's been totally sorted out elsewhere. It's one thing to write up a script in D which will handle the specific situation of dmd or druntime or Phobos. It's quite another to write a generic build tool.

I think that we could write a nice, clean build script for Phobos (or dmd or druntime) in D which specifically handled it without any attempt to generalize it and end up with something much better than make. But leave the standard D build tool stuff up to the likes of dub and orbit until they are ready to be used with dmd, druntime, and Phobos.

- Jonathan M Davis

On 8/12/2013 4:59 PM, Nick Sabalausky wrote:
> Perhaps surprisingly though, I don't actually use ls on windows - but
> that's only because the win version doesn't give much (any?)
> visual distinction of directories vs files. Instead, I stuck an
> "ls.bat" in my windows directory that invokes "dir /w %*". Probably my
> #1 most used command, aside from maybe cd.

You can set the default switches that DIR uses by setting the DIRCMD environment variable:

    set DIRCMD=/w

I use:

    set DIRCMD=/O:D/P

On 8/12/13 4:18 PM, Walter Bright wrote:
> 3. Make doesn't come preinstalled on Windows. But we have a make we can
> throw in the bin directory without issues. It's only 50K. Nobody goes
> out of their way - it's there on the same path as dmd. It's always the
> right version of make to use with our makefiles. We're not going to get
> into the Python distribution business.
>
...
>
> We did have a problem on FreeBSD because the default make on it would
> not work with posix.mak. gmake had to be explicitly installed. The only
> saving grace there is that very few people use FreeBSD, and those that
> do, tend to be pretty handy with installing gmake.

From these two paragraphs above it seems that distributing a statically-linked version of gmake instead of the current make would be a possible solution. It is bigger but that shouldn't matter.

Then we get to build on all supported OSs with posix.mak.

Given that gmake is GNU-licensed, would that be a problem?


Andrei

On 8/12/13 4:59 PM, Nick Sabalausky wrote:
> On Mon, 12 Aug 2013 11:06:37 -0700
> Sean Kelly <sean@invisibleduck.org> wrote:
>
>> 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.
>
> I can second that.

Is is possible from a licensing standpoint to just distribute a copy of gmake built by gnuwin?

Andrei

On 8/12/2013 5:41 PM, Andrei Alexandrescu wrote:
>  From these two paragraphs above it seems that distributing a statically-linked
> version of gmake instead of the current make would be a possible solution. It is
> bigger but that shouldn't matter.
>
> Then we get to build on all supported OSs with posix.mak.
>
> Given that gmake is GNU-licensed, would that be a problem?

I responded to that in some detail in my reply to Brad in this thread.