On 2015-01-14 20:50, Andrei Alexandrescu wrote:

> Currently there must be a place where druntime finds dmd for building
> purposes. Also phobos needs to find druntime. Also dlang.ord needs to
> find the source of both phobos and druntime.
>
> There's no specific setup of one person as much as a boring:
>
> /some/dir/
>    dmd
>    druntime
>    phobos
>    dlang.org
>    tools
>
> I have a hard time making it any simpler.

Last time I tried to build the docs in dlang.org, quite a long time ago. The d-programming-language.org repository just had been moved to dlang.org. So I update the repository URL, pull the new code and tried building the docs. Nothing worked because I had forget to rename the directory. A super repository with submodules would have solved this.

> Where would that super-repo sit?

https://github.com/D-Programming-Language/dlang for example

-- 
/Jacob Carlborg

On 2015-01-14 21:54, Andrei Alexandrescu wrote:

> I hear you but The Internet says submodules are a kind of a bummer.

Most issues I have read about is because they don't know how submodules work. It's the same thing with most tools, if you don't know how to use it the experience is going to be crappy.

I'm hoping the submodules can be automatically update, i.e. on a push to some of the submodules. I'm expecting most work to be done in the submodules and the super repository will be kept in sync automatically.

-- 
/Jacob Carlborg

On 2015-01-15 02:48, Rikki Cattermole wrote:

> Dub can run external processes but its best to leave it up to the end
> dev to run the c/assembly generation. When they want it regenerated.
> I think its best we commit most of the binary outputs.
> Mostly c/assembly generation. Not the D stuff.

Why don't you want to build the C/assembly stuff? The user is already expected to have a C compiler installed.

-- 
/Jacob Carlborg

On 15/01/2015 8:35 p.m., Jacob Carlborg wrote:
> On 2015-01-15 02:48, Rikki Cattermole wrote:
>
>> Dub can run external processes but its best to leave it up to the end
>> dev to run the c/assembly generation. When they want it regenerated.
>> I think its best we commit most of the binary outputs.
>> Mostly c/assembly generation. Not the D stuff.
>
> Why don't you want to build the C/assembly stuff? The user is already
> expected to have a C compiler installed.

Imagine your wanting to get some new flash feature (doesn't require compiler change) by just adding druntime/phobos as a dependency via dub.
You don't really want to recompile the assembly/c stuff that almost definitely hasn't changed.

Not many people may want to do that. But it should be reasonable to do so.
But this is mostly a Windows issue then posix. There its pretty well defined. Windows ergg.

On 2015-01-15 09:30, Rikki Cattermole wrote:

> Imagine your wanting to get some new flash feature (doesn't require
> compiler change) by just adding druntime/phobos as a dependency via dub.
> You don't really want to recompile the assembly/c stuff that almost
> definitely hasn't changed.

Why not? It's more likely you'll run in to problems with forgetting to compile it when it really has changed.

> Not many people may want to do that. But it should be reasonable to do so.
> But this is mostly a Windows issue then posix. There its pretty well
> defined. Windows ergg.

If it's only a problem on Windows, don't compile it on Windows :). The other platforms should suffer because of this.

-- 
/Jacob Carlborg

On 16/01/2015 1:19 a.m., Jacob Carlborg wrote:
> On 2015-01-15 09:30, Rikki Cattermole wrote:
>
>> Imagine your wanting to get some new flash feature (doesn't require
>> compiler change) by just adding druntime/phobos as a dependency via dub.
>> You don't really want to recompile the assembly/c stuff that almost
>> definitely hasn't changed.
>
> Why not? It's more likely you'll run in to problems with forgetting to
> compile it when it really has changed.

In this case I think its pretty close between checking in and not.
Atleast for me, I generally keep my D environment separate from e.g. VC so things like this could get difficult unless it was configured per machine like it is for dmd.

>> Not many people may want to do that. But it should be reasonable to do
>> so.
>> But this is mostly a Windows issue then posix. There its pretty well
>> defined. Windows ergg.
>
> If it's only a problem on Windows, don't compile it on Windows :). The
> other platforms should suffer because of this.

Technically there is one assembly file required by druntime for Windows that can't even be compiled on any 32 or 64bit computer... and is checked into git.

On Thursday, 15 January 2015 at 07:33:38 UTC, Jacob Carlborg wrote:
> On 2015-01-14 21:54, Andrei Alexandrescu wrote:
>
>> I hear you but The Internet says submodules are a kind of a bummer.
>
> Most issues I have read about is because they don't know how submodules work. It's the same thing with most tools, if you don't know how to use it the experience is going to be crappy.
>
> I'm hoping the submodules can be automatically update, i.e. on a push to some of the submodules. I'm expecting most work to be done in the submodules and the super repository will be kept in sync automatically.

We have been using git submodules for internal dependencies of Sociomantic projects for quite a while. It is not perfect but it works good if you defines terms of usage strict enough.

In this specific case I think it may work with help of few shell scripts that may reside in same top-level repo. Actually I do remember someone already trying that setup but can't find the links now. Anyone with better memory?

Important thing here is that starting with git 1.8.2 it is possible to set submodule to track head of remote branch instead of fixed commit hash - which fixes the maintenance issue and is exactly the thing needed for meta-dlang repo.

On Thu, Jan 15, 2015 at 04:08:14PM +0000, Dicebot via Digitalmars-d wrote:
> Important thing here is that starting with git 1.8.2 it is possible to set submodule to track head of remote branch instead of fixed commit hash - which fixes the maintenance issue and is exactly the thing needed for meta-dlang repo.

Very nice!! I wasn't aware of that... I must be behind the times. :-P

@Andrei: I think this nullifies about 50% of the naysayers' arguments against git submodules. Another issue is also that people used git submodules for things it wasn't intended for, and got burned as a result. Not really the fault of the feature. There *are* still some things to be desired, though, so it's not quite perfect yet. But it should be a lot more usable than before.


T

-- 
What are you when you run out of Monet? Baroque.

On 1/15/15 10:27 AM, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Jan 15, 2015 at 04:08:14PM +0000, Dicebot via Digitalmars-d wrote:
>> Important thing here is that starting with git 1.8.2 it is possible to
>> set submodule to track head of remote branch instead of fixed commit
>> hash - which fixes the maintenance issue and is exactly the thing
>> needed for meta-dlang repo.
>
> Very nice!! I wasn't aware of that... I must be behind the times. :-P
>
> @Andrei: I think this nullifies about 50% of the naysayers' arguments
> against git submodules. Another issue is also that people used git
> submodules for things it wasn't intended for, and got burned as a
> result. Not really the fault of the feature. There *are* still some
> things to be desired, though, so it's not quite perfect yet. But it
> should be a lot more usable than before.

I'd be okay with reorganizing our repos as a module with the submodules dmd, druntime, phobos, and tools. For that we'd need a champion who is willing to try it, experiment with it (e.g. in a separate repo), demonstrate its advantages and discuss its disadvantages, and carry the actual porting work.

It seems to me we'd need to derive a few more advantages than solving the particular matter I opened this thread with.


Andrei