Monorepo? (page 4)

Settings

Help

Index » General » Monorepo? (page 4)

February 07, 2023

Re: Monorepo?

Posted by Iain Buclaw
in reply to Adam D Ruppe

Permalink

Iain Buclaw

Posted in reply to Adam D Ruppe

Permalink

On Monday, 6 February 2023 at 23:49:54 UTC, Adam D Ruppe wrote:
> On Monday, 6 February 2023 at 23:42:01 UTC, Iain Buclaw wrote:
>> Goodbye -release, goodbye -dip1000, goodbye -checkaction=, goodbye -preview=, goodbye -debug=, goodbye -unittest, goodbye -version=, goodbye -allinst...
>
> i have a potential solution
>
> http://dpldocs.info/this-week-in-d/Blog.Posted_2022_11_14.html#redesign-for-template-emission-woes

Agreed that none of them are strictly bugs once you explain the rationale.

There are historically two ways to go about it.

1. Reference a template repository during building of each module, package, library, project, ...; whichever way your build is broken down into.  Add templates to the repo as you progress through building your project.

2. Go gung-ho with emissions, relying on "used" flags to determine whether any calls/address references to the symbol actually remain in the graph (after inlining), and prune it all away before writing to assembly/object file.

February 06, 2023

Re: Monorepo?

Posted by Steven Schveighoffer
in reply to Iain Buclaw

Permalink

Steven Schveighoffer

Posted in reply to Iain Buclaw

Permalink

On 2/6/23 6:35 PM, Iain Buclaw wrote:

On Monday, 6 February 2023 at 20:21:35 UTC, Steven Schveighoffer wrote:

All agreed. We should have a standing rule that any tests that are run based on code external to dmd/druntime need to happen after all the dmd/druntime tests are done. And tools should be built with a known good compiler. The "checkwhitespace" problem seems an incredibly foolish requirement to shove in front of making sure you have a sane compiler.

You're not really going to believe that checkwhitespace is built with the compiler under test, are you? ;-)

I haven't looked. Just going by what Walter said. If it is, it shouldn't be.

-Steve

February 06, 2023

Re: Monorepo?

Posted by Steven Schveighoffer
in reply to H. S. Teoh

Permalink

Steven Schveighoffer

Posted in reply to H. S. Teoh

Permalink

On 2/6/23 3:46 PM, H. S. Teoh wrote:

On Tue, Feb 07, 2023 at 09:34:08AM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:

On 07/02/2023 9:05 AM, Walter Bright wrote:

On 2/6/2023 11:38 AM, Iain Buclaw wrote:

Because somebody wanted a power operator.

Maybe that should be revisited (i.e. use a function rather than an
operator).

Nah, its just the implementation is in the wrong place and its
implementation needs revisiting.

https://issues.dlang.org/show_bug.cgi?id=23538

Since ^^ is a built-in operator in the language, the implementation (and
its dependencies) really should be in druntime. Any dependent functions
like exp() that's currently in std.math should be moved to druntime, and
std.math should just alias the current symbol to the druntime
implementation.

Yes. That's what has happened with all the other intrinsics, though this sounds less like an intrinsic, and more like a magic symbol.

Or, alternatively. Create a small Phobos with just the pieces needed to make the test suite run, and don't ever change it.

-Steve

February 07, 2023

Re: Monorepo?

Posted by Atila Neves
in reply to user1234

Permalink

Atila Neves

Posted in reply to user1234

Permalink

On Monday, 6 February 2023 at 18:15:00 UTC, user1234 wrote:

On Monday, 6 February 2023 at 17:56:33 UTC, Atila Neves wrote:

On Monday, 6 February 2023 at 17:09:36 UTC, user1234 wrote:

On Monday, 6 February 2023 at 10:22:32 UTC, Atila Neves wrote:

[...]

This could lead to more breaking changes. Monorepo means that only BuildKite will be able to detect them, unless it is specified that it's not allowed to commit changes in phobos just because required by a change in dmd/druntime.

The need for this rule says it all.

I don't understand, could you please explain how there'd be more breaking changes?

I'll try to reword a bit:

In case of an unexpected breaking change that would manifest itself only in the Phobos test suite and not in the BuildKite CI, and without "the rule", authors will be tempted to fix the problem in phobos in the same PR as the one initially only supposed to change DMD.

As special rule is required, then why put phobos in the main D repo ?
The fact that a special rule is required is a sign that a monorepo is a bad idea.

What special rule? If a dmd change breaks Phobos, doesn't it make more sense to fix Phobos in the same PR than submitting a separate PR to the Phobos repo (and having to explain that it's because of dmd PR #12345)?

February 07, 2023

Re: Monorepo?

Posted by Atila Neves
in reply to deadalnix

Permalink

Atila Neves

Posted in reply to deadalnix

Permalink

On Monday, 6 February 2023 at 22:58:02 UTC, deadalnix wrote:

On Monday, 6 February 2023 at 15:04:24 UTC, Iain Buclaw wrote:

On Monday, 6 February 2023 at 14:28:45 UTC, max haughton wrote:

Things choosing and thus eventually disagreeing on which Phobos version they want to use is potentially not so great.

Phobos being pre-compiled with an unknown set of flags, and that mismatching every other project reliant on Phobos is not great either.

This is generally not a problem with C++, why should we expect this to be one for D?

If we introduced flags that bifurcate the language, then it seems to me that these flags should be removed.

It's curious now that you mention it that C++ doesn't have this problem, seeing as how they also have a lot of compiler flags. Off the top of my head I can't figure out why.

February 07, 2023

Re: Monorepo?

Posted by deadalnix
in reply to Atila Neves

Permalink

deadalnix

Posted in reply to Atila Neves

Permalink

On Tuesday, 7 February 2023 at 10:33:58 UTC, Atila Neves wrote:

> >

If we introduced flags that bifurcate the language, then it seems to me that these flags should be removed.

It's curious now that you mention it that C++ doesn't have this problem, seeing as how they also have a lot of compiler flags. Off the top of my head I can't figure out why.

The flags don't tend to create a new, incompatible, language.

What is affected by the flag of the consumer is provided as templates and/or macros.

February 07, 2023

Re: Monorepo?

Posted by Iain Buclaw
in reply to deadalnix

Permalink

Iain Buclaw

Posted in reply to deadalnix

Permalink

On Tuesday, 7 February 2023 at 14:37:35 UTC, deadalnix wrote:

On Tuesday, 7 February 2023 at 10:33:58 UTC, Atila Neves wrote:

> >

If we introduced flags that bifurcate the language, then it seems to me that these flags should be removed.

It's curious now that you mention it that C++ doesn't have this problem, seeing as how they also have a lot of compiler flags. Off the top of my head I can't figure out why.

The flags don't tend to create a new, incompatible, language.

Erm... yes they do (C/C++ flags).

February 07, 2023

Re: Monorepo?

Posted by jmh530
in reply to Atila Neves

Permalink

jmh530

Posted in reply to Atila Neves

Permalink

On Monday, 6 February 2023 at 10:22:32 UTC, Atila Neves wrote:

Now that dmd/druntime is in one repo, is there a good reason to not include Phobos?

I would recommend a discussion and vote (among normal participants) at one of the upcoming Dlang foundation monthly meetings. Ask two people to kick off the discussion with each one taking a different side (invite someone who doesn't typically attend those meetings if needed).

One thing that might be useful to this discussion is some kind of criterion that participants can to judge the decision. Any choice will have pros and cons, but how do you judge what is most important?

Are you trying to make the build process as smooth as possible? Or maybe to optimize dmd/druntime developers' time? Or maybe to minimize breakage in phobos from dmd/druntime changes? Or maybe to minimize burdens on new contributors? Or maybe some balance of these potentially conflicting objectives.

February 07, 2023

Re: Monorepo?

Posted by ryuukk_
in reply to Richard (Rikki) Andrew Cattermole

Permalink

ryuukk_

Posted in reply to Richard (Rikki) Andrew Cattermole

Permalink

On Monday, 6 February 2023 at 19:13:35 UTC, Richard (Rikki) Andrew Cattermole wrote:
> I am very much not a fan of horror movies. Let alone at 8am.
>
> Let's not explore such horror topics such as mixing two sets of teams code bases which absolutely needs to be completely isolated from one another in such early hours.
>
> But seriously, WHY ARE THERE COMPILER HOOKS IN PHOBOS (std.math)!

I agree with that, the standard library is a library, it should be a separate thing

The runtime lives with the compiler, making it easier to port the whole thing to new targets instead of having to do a whole mess all at once

February 08, 2023

Re: Monorepo?

Posted by Richard (Rikki) Andrew Cattermole
in reply to Atila Neves

Permalink

Richard (Rikki) Andrew Cattermole

Posted in reply to Atila Neves

Permalink

On 07/02/2023 11:15 PM, Atila Neves wrote:
> What special rule? If a dmd change breaks Phobos, doesn't it make more sense to fix Phobos in the same PR than submitting a separate PR to the Phobos repo (and having to explain that it's because of dmd PR #12345)?

If a Phobos change breaks MIR, doesn't it make more sense to fix MIR in the same PR than submitting a separate PR to the MIR repo (and having to explain that its because of a Phobos PR #12345)?

We can apply this same logic to literally any code base that is in the auto tester. The dmd repository is going to get quite big when we keep including what should be isolated code bases administratively...

Personally I'm not sure that the zlib folks are going to want to move development into the dmd repository. But hey, you guys have pull so maybe you'll archive it!

Top | Forum index | About this forum

Forums