On Tue, 2013-08-13 at 09:09 +0200, Jacob Carlborg wrote:
> On 2013-08-12 20:06, Russel Winder wrote:
> 
> > 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.
> 
> Why don't they embed Python inside SCons, at least as an option.

SCons is a Python application and so is normally installed in the Python installation. I am sure there could be a Windows installer created, but I guess most Windows people use Visual Studio (*). No package-based system really needs Python shipped with SCons as it is so trivial to install Python and then SCons. OS X comes with Python pre-installed, though it is an old version (**).

The reality here is that most major Fortran, C and C++ places are either politically opposed to Python, or are already using it. The former are incapable of using SCons and the latter would get annoyed by another Python installation when they already have one.  Most HPC places are using SciPy, most banks now use Python, most engineering places are using Python.


(*) SCons can create Visual Studio projects.

(**) Anyone using Python earlier than 2.7 is either contractually obliged or nuts. Most sensible folk are already using Python 3.3 or rapidly moving towards it.  SCons sadly is not Python 3 compatible. At least not yet, but there are plans.

-- 
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 Tuesday, 13 August 2013 at 06:56:11 UTC, Jacob Carlborg wrote:
> No, it's not portable. Example, libraries on Posix are usually named "libfoo.a", on Windows they're named "foo.lib". As far as I know that is not handled by pragma(lib).

Yes, it is. pragma(lib, "foo") works on both systems. It passes the name "foo" to the linker, which knows about the cross platform differences. I use it all the time on Windows and Linux without any problems.


The problem people have with pragma(lib) is that gdc's architecture doesn't allow it; the front end in gcc can't pass an argument to the linker, and also that separate compilation with any compiler doesn't pass the pragma (its instruction is only in the .d file, not the .o). I don't see this as a problem with the feature - it doesn't have to work in every case to be very useful.

worst case, if it doesn't work, you're just doing it the way you would anyway. Even so, however, pragma(lib) can still serve to document the fact that the library is required.

In summary, pragma(lib) is great and you can have it when you pry it from my cold, dead hands.

On Tuesday, 13 August 2013 at 05:05:35 UTC, Jonathan M Davis wrote:
> (though it loses its history if you change to a different tty)

Yeah, though there's an easy solution here too: gnu screen! Though shift+pageup doesn't quite work even there, if you change ttys it does clear that buffer, but screen's own scrollback is still there, hit C-a [ to go into copy mode and you can scroll around it). There are some minor bugs with screen and gpm (the text mode mouse driver), but overall it works well.

Of course, screen works just as well on putty, xterm, and just about anything else. On my laptop's putty shortcut, I have it automatically run screen for me, so it resumes my session and offers the nice C-a a feature all the time (though on the laptop I rebound that to C-s due to the shape fo the keyboard, and to make nesting screens easier). I love it.

On Saturday, 10 August 2013 at 18:35:10 UTC, Nick Sabalausky wrote:
> Would it be
> acceptable to use gmake as *the* make for DMD? Ie, either convert the
> windows makefiles to gmake, or expand the posix makefiles to support
> windows?

1. expand posix makefiles to support windows
2. leave dm makefile for those who doesn't have gmake
3. use unified posix/windows makefile
4. everyone is happy

On Tue, Aug 13, 2013 at 11:55:12AM +0200, Joakim wrote: [...]
> Personally, I like the D-based build system idea.  Distribute dmd/phobos with a D-based build tool like dub, which has been compiled ahead of time for each supported platform and will compile D for you, if you want.  Of course, this means that you'll still need to maintain makefiles on the D build machines that will build dub for the D maintainers to distribute, but it isolates all the complexity of makefiles from end users, so they don't have to touch any of that stuff.  Whether that ease of use is worth the extra effort, I don't know.

There's no need to maintain any makefiles once the D build tool is usable. As long as you have a working binary of dmd that can compile the tool, that's good enough.


T

-- 
For every argument for something, there is always an equal and opposite argument against it. Debates don't give answers, only wounded or inflated egos.

On Tue, Aug 13, 2013 at 09:03:12AM +0200, Jacob Carlborg wrote:
> On 2013-08-12 00:38, H. S. Teoh wrote:
> 
> >Maybe my previous post didn't get the idea across clearly, so let me try again. My underlying thrust was: instead of maintaining 3 different makefiles (or more) by hand, have a single source for all of them, and write a small D program to generate posix.mak, win32.mak, win64.mak, whatever, from that source.
> 
> If it's written in D it will have the same bootstrap problem. But perhaps that's ok since we're moving DMD to D anyway.
[...]

Well, yes, we're moving DMD to D anyway, so we're going to face the bootstrap problem regardless.

But that's not really what I'm getting at.  My whole point was to have a "single source of truth" for how to build what needs to be built, instead of scattering it across 3+ makefiles that need to be maintained separately.


T

-- 
Never wrestle a pig. You both get covered in mud, and the pig likes it.

On Tuesday, 13 August 2013 at 16:11:44 UTC, H. S. Teoh wrote:
>
> There's no need to maintain any makefiles once the D build tool is usable.

On this note, I've often wondered why D compilers (or dmd, at least) don't just try to infer the necessary files to compile/link for a project based on the modules it imports.  Obviously this breaks down once you need to express linkage with external libraries; but figuring out as much as possible automatically would be neat.

e.g.
Say the top of smallProj.d has:
import common.func;
import common.data;

...and you have a common/ directory with func.d and data.d, it seems the compiler could accept:
dmd smallProj.d
...as a shorthand for:
dmd common/func.d common/data.d smallProj.d

Given that it doesn't work this way, I'm guessing there's some aspect I've missed that throws it into the same sort of hellscape of agony as every other build system in the world, but I can't figure out what it might be...

-Wyatt

On Tuesday, 13 August 2013 at 16:39:06 UTC, Wyatt wrote:
> Given that it doesn't work this way, I'm guessing there's some aspect I've missed that throws it into the same sort of hellscape of agony as every other build system in the world, but I can't figure out what it might be...

It exactly what rdmd does. Merging this functionality into dmd itself was discussed but not done.

On Tue, 13 Aug 2013 11:55:12 +0200
"Joakim" <joakim@airpost.net> wrote:

> On Tuesday, 13 August 2013 at 08:30:26 UTC, Walter Bright wrote:
> > On 8/12/2013 11:48 PM, Jacob Carlborg wrote:
> >> On 2013-08-13 02:42, Andrei Alexandrescu wrote:
> >>
> >>> Is is possible from a licensing standpoint to just distribute
> >>> a copy of
> >>> gmake built by gnuwin?
> >>
> >> I don't see why we couldn't do that. It's a completely
> >> separate tool and
> >> shouldn't "infect" anything else. We might need to accompany
> >> it with a license
> >> file and a link to the source code to be on the safe side.
> >>
> >
> > Again, read my reply to Brad in this thread.
> 
> Presumably you are referring to this quote, which does not show up as a reply?
> 
> 

I think he's referring to technical issues with gmake apparently not always playing nice on windows.

On Tue, 13 Aug 2013 09:03:12 +0200
Jacob Carlborg <doob@me.com> wrote:

> On 2013-08-12 00:38, H. S. Teoh wrote:
> 
> > Maybe my previous post didn't get the idea across clearly, so let me try again. My underlying thrust was: instead of maintaining 3 different makefiles (or more) by hand, have a single source for all of them, and write a small D program to generate posix.mak, win32.mak, win64.mak, whatever, from that source.
> 
> If it's written in D it will have the same bootstrap problem.

Sort of, but...no, not really.

Since this tool would be cable of generating any platform-specific makefile or script or whatever, and there's no reason to restrict it to *only* generate a makefile/script for the current platform, that means it can function much like a cross-compiler:

Suppose there's some computer DMD isn't installed on. Maybe it's even a new platform that DMD hasn't been ported to. H.S. Teoh's tool could be run on *any existing* D-capable system to generate the makefile/script for the intended target computer. Maybe that might even require adding a new shell/makefile output to the tool, but it would *not* require running H.S. Teoh's tool (or anything else) on the actual intended target platform.

Then, that makefile/script which was generated on...windows or whatever...is then transferred (email, ftp, floppy, whatever) to the new system and DONE - a working buildscript, ready to attempt compiling DMD, without *anything* having been run yet.


> But perhaps that's ok since we're moving DMD to D anyway.
>