Moved the K submodule into the deps directory

[charala1]

modified:

• Dockerfile
• Makefile
• .gitmodules
• .build/k -> deps/k

[dwightguth]

@ehildenb what do you think about this change? I tend to agree with Minas that it's better not to have dependency submodules in a hidden directory that also contains build outputs. But I don't want to make this change unless we commit to changing it consistently.

[charala1]

@ehildenb what do you think about this change? I tend to agree with Minas that it's better not to have dependency submodules in a hidden directory that also contains build outputs. But I don't want to make this change unless we commit to changing it consistently.

@dwightguth The c-semantics submodule is not in a hidden directory in rv-match, but the k back-ends are in hidden directories inside the k project folder. I agree this change should be propagated everywhere.

[ehildenb]

@dwightguth I'm not opposed to this change, but I don't think I'll make it for KEVM and KWasm unless there is a good quantitative argument about how it makes dev-work easier. I personally like limiting how many things are stored directly in the root of the repo because I like to show people the repo on GitHub during demos (so we get nice formatting), and I think it gets confusing to do that when there are lots of extra files.

I would be open to changing it to a non-hidden directory called deps if you like. I do not think it's worth the effort to do out-of-tree builds for our dependencies. For me doing builds in a file that is .gitignoreed counts as "out-of-tree".

[ehildenb]

I am opposed to any solution which does builds outside the repository root directory though, because I am opposed to cluttering any other directories on the users system.

[charala1]

I am opposed to any solution which does builds outside the repository root directory though, because I am opposed to cluttering any other directories on the users system.

Just to clarify, I am opposing this too -- except as directed by the user. Much like autotools uses --prefix and/or the make PREFIX variable, or how using cmake entails cd some/dir && cmake /path/to/src && make.

[dwightguth]

If we're not going to change kevm, we should not change c-semantics. That said, I like the idea of dependency submodules living in a deps directory under the root better than them living under a .build directory. Is this something we can agree to propagate across all our semantics? I think it makes the repository significantly easier to explain if we separate build artifacts from source code in the directory structure, even if it adds an extra directory.

[charala1]

If we're not going to change kevm, we should not change c-semantics. That said, I like the idea of dependency submodules living in a deps directory under the root better than them living under a .build directory. Is this something we can agree to propagate across all our semantics? I think it makes the repository significantly easier to explain if we separate build artifacts from source code in the directory structure, even if it adds an extra directory.

I agree, placing things inside a new directory deps/ or external-deps/ or similar makes things much more obvious and clean.

[ehildenb]

@dwightguth I can agree to move dependencies to a deps directory and continue to do builds in the .build directory (or in a build directory).