search

rolandshacks / vs64

C64 Development Environment for Visual Studio Code
Other
88 stars 15 forks source link

.ninja_log not deleted on new build #35

Closed Rytikar closed 1 year ago

Rytikar commented 1 year ago

Hi, I'm experiencing a funny issue. A build went file, creating the artefacts including .ninja_log. I then make changes, and on save a new compile starts, saying all fine 'ninja: no work to do'. But it had not built, not showing the errors. When I then delete .ninja_log manually it builds again, until success, then creating a new .ninja_log and the problem repeats. Something wrong or user error?

Regards and thanks

rolandshacks commented 1 year ago

Hi,

In case you're using several source modules, could you try adding all source files to the "sources" list at the project file? Alternatively, it would be great to get a "failing example" to reproduce your setup.

Regards, Roland

Rytikar commented 1 year ago

Yes, several .asm files. I’ll try that and come back tomorrow. Thanks for the fast answer.

rolandshacks commented 1 year ago

I found the bug. ACME does not create a dependency information file (like clang or gcc do) - therefore, the extension is creating a compatible file by its own. Bug: it's created once when the ninja.build file is generated... ninja is smart and auto-deletes the dependency file, and afterwards, no more dependency information exists ...

Try to do the fix asap...

Thanks for the report!!!

rolandshacks commented 1 year ago

Bug should be fixed with version v2.1.3.

It is on the vscode marketplace and you should get auto-updated whenever you restart vscode.

Please let me know if this solves your issues.

Thanks.

Rytikar commented 1 year ago

It updated fine, but... 'failed to spawn process '/home/rh/.vscode/extensions/rosc.vs64-2.1.3/resources/ninja/linux/ninja: EACCES'

rolandshacks commented 1 year ago

I built the extension now on linux, maybe you could try v2.1.4. My guess is that on windows, the exe flags for the ninja executables are getting lost. Damn.

Rytikar commented 1 year ago

Works now, thanks.

Btw, I've added my additional files to main.asm as: !source "./src/labels.asm", 8 files at all. If I add them to the sources section in config build fails?

rolandshacks commented 1 year ago

Good! Yes, adding the asm sources doesn't make sense if they're included files - and leads to build failures. Just keep them out of the project file and leave it to vs64 to scan and auto-detect the dependencies.

rolandshacks commented 1 year ago

In case you're planning to open-source your project - let me know once it's public. I'd be happy for more test projects...

Rytikar commented 1 year ago

Hehe.., well we're talking about this baby: https://www.youtube.com/watch?v=84hIKDUIpsM&t=41s The 'real' game is shown at minute 4, the rest is all intro stuff.

As for 'open sourceing it', you can get the game as d64 for vice.

I'm one of the original authors and, after nearly 40 years, got the urge to see if I can get it buildable again. We're talking a four disks game here, full of assets. And countless tools made in assembler, basic and hypra-basic (I think). I've nearly forgotten all about it, but I still have my disk box from 1985. Nearly never opened since, but it's all there.

This guy triggered it all: http://crpgaddict.blogspot.com/2018/03/game-283-nippon-1988.html His 'complaints' and rating are fair, but can think of possible updates for a 'Nippon Reloaded'.

I know, I'm crazy. Don't ask why, as the answer is only 'because I can'. :-)

But you're welcome to assist, I definitely need some play testers, as this is what was missing most then.. it compiled, ship it...

And, judging from you're name, I don't think the German is a problem for you, right? On the other hand, an English translation is on top of my TODO list...

rolandshacks commented 1 year ago

Hey, this is great. More than happy to support you with features "just-in-time" as my schedule allows. And you're right, German is indeed no problem. Feel free to reach out via PM!

rolandshacks commented 1 year ago

Also, for tooling - what would you think are important ones? Not sure if I would overload and over-engineer vs64, but maybe there could be a few little things (at least, I could try to open up the build kit for custom tooling).