Establish tooling, libraries and initial build process

[ChronosWS]

We need to select the initial operating system target, languages, tools and libraries we are going to use and create an initial build process for the source tree.

Recommend:

OS: Windows (Linux as well?) Language: D Compiler toolchain: (DMD or Gnu?) Libraries:

• Phobos, with std.logger experiemental
• Deviare hook library for Windows (http://www.nektra.com/products/deviare-api-hook-windows/)
• Others? Build:
• MSBuild? Make? DUB?

[chuckeng-htc]

We need to select the initial operating system target, languages, tools and libraries we are going to use and create an initial build process for the source tree.

Recommend:

OS: Mac OS X Windows (Linux as well?) Language: D Compiler toolchain: (DMD or Gnu?) Libraries:

• Phobos, with std.logger experiemental
• Deviare hook library for Windows (http://www.nektra.com/products/deviare-api-hook-windows/)
• Others?

— Reply to this email directly or view it on GitHubhttps://github.com/JoyfulCode/Providence/issues/2.

[ChronosWS]

If we have enough people to do parallel development on all three platforms, that'd be fantastic, as we can sort out the cross-platform procedures immediately. I don't have a Mac here, I could set up a VM for Linux pretty easily but maintaining both platforms locally might be time consuming.

[chuckeng-htc]

Here is where you get one: http://apple.com

Then buy VMWare Fusion Pro.

With this, I run OSX, Windows, and Linux.

From: Cliff Hudson notifications@github.com<mailto:notifications@github.com> Reply-To: JoyfulCode/Providence reply@reply.github.com<mailto:reply@reply.github.com> Date: Thursday, October 2, 2014 at 3:44 PM To: JoyfulCode/Providence Providence@noreply.github.com<mailto:Providence@noreply.github.com> Cc: Chuck England chuck_england@htc.com<mailto:chuck_england@htc.com> Subject: Re: [Providence] Establish tooling, libraries and initial build process (#2)

If we have enough people to do parallel development on all three platforms, that'd be fantastic, as we can sort out the cross-platform procedures immediately. I don't have a Mac here, I could set up a VM for Linux pretty easily but maintaining both platforms locally might be time consuming.

— Reply to this email directly or view it on GitHubhttps://github.com/JoyfulCode/Providence/issues/2#issuecomment-57721448.

[quickfur]

I'm a Linux user. I'll be sure to complain loud and clear if something doesn't work on Linux. :-P No need to buy a Linux VPS unless I vanish off the face of the 'Net or something. :-P

[ChronosWS]

Ok, great. One thing then you might want to look for is a library or method we can implement to intercept OS calls (needed for isolation and environment sanitization and potentially filesystem redirection.) I don't know enough about Linux these days to answer these, so you might have a leg up on figuring that out.

[quickfur]

Hmm. I could take a look at Tup to see how they do it... AFAICT, it's just using LD_LIBRARY_PATH to override the system libc functions to forwarding wrappers that capture information about what file(s) are opened, etc.. No actual filesystem redirection is needed unless we're talking about debugging our own code.

[ChronosWS]

That's probably a fine place to start and we can iterate from there then.

[quickfur]

Now as far as compiler toolchain is concerned... I think it's best to test with both dmd and gdc. But for the sake of not having to maintain two separate sets of compiler flags (I've actually done this, and it's not pretty), we can use the gdmd wrapper around gdc so that we only need to use dmd-style flags.

[quickfur]

I think make is probably the most cross-platform option for our initial stage, before the project becomes self-hosting. As long as we stick to the bare minimum make syntax (i.e., no GNU extensions or Windows-specific stuff), we should be able to use the same makefile for everything, which will avoid problems of having to maintain all the other versions of the makefiles every time we change one.

[quickfur]

Oh BTW, does Windows have something akin to Linux's inotify that notifies a process of filesystem changes? Just wondering how different it would be, which might necessitate the appropriate design changes to accomodate both OS implementations.

[ChronosWS]

Yes, there are file system notifications you can plug in to on windows, I think they are roughly analogous to what is available on Linux, but I have not used them before.

Another option is to create a virtual filesystem which tracks reads and writes and optionally can do things like keep hashes up-to-date. Such a thing is definitely more complicated but it brings other possibilities (like replication in the distributed case for example.) But that is more of a long-term option rather than something we will need immediately, so I am not too worried about it.

[ChronosWS]

Initial commit of makefile, app and directory structure completed. Please validate and update for Linux/Mac as needed - I tried to avoid anything OS specific.

I have not included the gdmd wrapper yet - H.S. if you could do this it would be much appreciated.

[quickfur]

Would it make sense to have a makefile at the top-level directory, so that people don't have to cd into src/app to build it?

[quickfur]

Also, just realized that we probably can't use the same makefile for all platforms, since Linux doesn't have the same file extensions as Windows. :-( Do you know if there's a platform-independent way of including a submakefile from a master makefile? I'm thinking we could have win.mak and posix.mak (and maybe osx.mak) to setup the platform-specific stuff, and then it will run the "main" makefile which contains the actual dependencies.What do you think?

[ChronosWS]

Having a top-level one is fine, feel free to add it.

As for common extensions, etc. It's been well over a decade since I last had to do anything serious with a makefile, so I don't know what the best way to split this stuff up is for platform differences. Since we aren't going to invest too much in a make-based system, the system you suggest above seems reasonable.