Force "Monkey: Clean Project" before run (or support outside project source folders)

What os are you using? In Unix, Mac you can make soft links so inside your project if you do: ln -s ../../shared/sec/core core, then you can have core in the jungle file.

I use symbolic links to share Monkey C code in Windows too. In Windows, creating a symlink requires UAC elevation by default, unless you enable developer mode (which is highly recommended.)

One problem is that VS Code does not handle symlinks very well on Windows (e.g. source code control integration, such as visual diffs, doesn’t work as expected.) I *think* it might be the same situation on MacOS but I haven’t checked lately. You can get around this problem by including the shared folder in your workspace and disabling the Search: Follow Symlinks option.

flocsy🤠 thanks for the suggestion, but this is something I wanted to avoid (for the reasons FlowState is mentionig) and because sym links are very undetectable visually on windows imho...

FlowState said:

You can get around this problem by including the shared folder in your workspace and disabling the Search: Follow Symlinks option.

You mean including the shared folder as a sym link? Not by using a relative path as I do?

My desired solution would be to make VSCode aware that it should watch ALL project folders (probably a monkeyc plugin issue I assume)...

Yes, I agree there's some strangeness even on Mac. My use case is a little bit different, but probably at the end it's the same:

source/Files.mc
AppA/source -> ../source
AppB/source -> ../source

and in VSC I open AppA/ as the "root" of the project (I also have the monkey.jungle, and of course of the manifest per app directory)

The strange thing is that some things work when I open "source/Foo.mc", but then if for example there's an exception then if I click on the stack trace then it opens another window of Foo.mc with the absolute path.

Michael said:

sym links are very undetectable visually on windows imho...

I use Link Shell Extension on Windows which provides:

- right-click / drop-and-drop support for creating several different kinds of links (including a recursive hardlink / symlink clone of an entire folder structure)

- separate explorer shell icon overlays for hard links, symlinks, and junctions (ofc this is subject to the hardcoded limit of 11 non-system shell icon overlays)

If you use the columnar details view in Explorer, you can also add the Link Target column which works for symlinks but not junctions.

Michael said:

You mean including the shared folder as a sym link? Not by using a relative path as I do?

Yeah, it's been a while since I've tried this out on Windows, but I mean:

- include the real external shared folder path in your workspace as you currently do

- also include a symlink to your shared folder under your project, to make Monkey C happy

- whenever you edit a shared file, open the real location and not a linked location

The purpose of disabling "Search: Follow Symlinks" is so you don't get duplicate search results.

Michael said:

My desired solution would be to make VSCode aware that it should watch ALL project folders (probably a monkeyc plugin issue I assume)...

While the Monkey C plugin does have issues which don't seem to affect plugins for other languages (such as a tendency to sometimes run the wrong project in a multi-root workspace, when you've focused an editor for the project you do want to run), I think the issue here is that VS Code's concept of a project is based on one root folder per project. VS Code allows for multi-root workspaces, but not multi-root projects.

EDIT: actually VS Code doesn't really support the concept of projects at all, so I guess it's really up to the Monkey C plugin as you said.

In your case, I'm sure that using the common parent of the shared folder as the project root wouldn't work bc that would include multiple projects and/or Monkey C probably expects certain files such as manifest.xml and monkey.jungle to be in top-level folder, by default.

Link Shell Extension and junction link solves the problem, thanks for the idea.

Just one issue:

*.mir files are created inside the shared folders next to the *.mc files - can I somehow set up everything that those mir files are only created inside the bin folder?

Michael said:

Link Shell Extension and junction link solves the problem, thanks for the idea.

Sure np. I will say that for maximum compatibility with source control (such as git) and other platforms, I would use a symbolic link instead (e.g. git can source control symlinks, but not junctions, and junctions are exclusive to NTFS).

Michael said:

*.mir files are created inside the shared folders next to the *.mc files - can I somehow set up everything that those mir files are only created inside the bin folder?

Funny, I played around with this and initially I found that creating a junction to a source folder outside of the project hierarchy (*) with one .mc file would cause the corresponding .mir file to be created in the source folder as you said, instead of the bin/mir folder as usual. (I placed the links themselves outside of the normal source folder, but within the project folder hierarchy, and set the sources property in monkey.jungle to add the original source folder as well as the new links.) I think the same thing happened with a symlink (although some other strange stuff seemed to be going on, so I can't be sure if I tested this properly.)

(*) This doesn't seem right, as junctions - unlike symlinks - should be completely transparent to applications (or at least, junctions should be "more" transparent than symlinks.) Another possibility could be that any non-default source folder would get this treatment, but I haven't investigated deeply enough.

Anyway, I deleted the .mir files and rebuilt - they were recreated in bin/mir.

Can't really explain it. If I get a chance I'll have to do a slower, more methodical test.

My project looked like this:

project_root
|
---source (real folder)
|
---source2 (real folder)
|
---source3 (junction to ..\sources3)
|
---source4 (symlink to ..\source4)

EDIT: after cleaning the project and rebuilding, this is where my mir files end up:

bin
|
---mir
|   |
|   --- source
|   |
|   --- source2
|
---source3

No sign of mir files for source4...

junction or symbolic links work now - the import thing is to NOT include the link folder but keeping including the relative real folders. The junction or symbolic link is just there for the IDE to know when to clear and rebuild the project instead of rerunning the last build.

I did change

srcBase = source;../../shared/src/core

to

srcBase = source;shared/src/core

and this had the side effect with the .mir files... and this change was not necessary.

Glad you found a workaround! I’m glad it works, but it does violate the DRY principle (don’t repeat yourself), since you basically have to specify the link target twice (once when you create the link, and another time in monkey.jungle). It would be ideal for the link itself to be the single source of truth that everyone else can refer to.

Oh well, for all practical purposes it’s nbd