Huhhh... I don't know why it would make a difference. It's obviously failing to setup cl for you, which is always a painful part of this build script.
Does that mean it's working for you now? I still want to take a look at this when I get a chance, but I'm afraid I don't have much more to suggest off the top of my head.
Does that mean it's working for you now? I still want to take a look at this when I get a chance, but I'm afraid I don't have much more to suggest off the top of my head.
Does it work any better if you run it from a plain old command prompt? That's what I did and it worked fine.
I don't know why you're getting that particular error, but I also don't know how rebuilding 4coder within 4coder would work (at least with its current architecture). In the process of building it tries to generate custom_4coder.dll, but while 4coder is running, that .dll is tied up, and I'd therefore expect things to fail during linking.
In fact I just ran a quick test -- renamed buildsuper.bat to build.bat and ran it within 4coder using alt-m -- and indeed it failed just as predicted.
So, I'd be curious to see if buildsuper.bat runs successfully within a regular cmd.exe terminal. If it does -- and based on your VSCode build output I suspect it will -- then personally I'd just leave it at that. To me, I wouldn't want to spend time trying to figure out why building within 4coder is failing in that particular way, given that building within 4coder isn't going to work anyway (due to the aforementioned dll issue).
I don't know why you're getting that particular error, but I also don't know how rebuilding 4coder within 4coder would work (at least with its current architecture). In the process of building it tries to generate custom_4coder.dll, but while 4coder is running, that .dll is tied up, and I'd therefore expect things to fail during linking.
In fact I just ran a quick test -- renamed buildsuper.bat to build.bat and ran it within 4coder using alt-m -- and indeed it failed just as predicted.
1 2 3 4 5 6 7 8 9 10 11 | ********************************************************************** ** Visual Studio 2017 Developer Command Prompt v15.6.7 ** Copyright (c) 2017 Microsoft Corporation ********************************************************************** [vcvarsall.bat] Environment initialized for: 'x64' 4coder_metadata_generator.cpp 4coder_default_bindings.cpp LINK : fatal error LNK1104: cannot open file 'custom_4coder.dll' Could Not Find C:\4coder\*.exp Could Not Find C:\4coder\*.lib exited with code 0 |
So, I'd be curious to see if buildsuper.bat runs successfully within a regular cmd.exe terminal. If it does -- and based on your VSCode build output I suspect it will -- then personally I'd just leave it at that. To me, I wouldn't want to spend time trying to figure out why building within 4coder is failing in that particular way, given that building within 4coder isn't going to work anyway (due to the aforementioned dll issue).
OK, so some updates. The build did indeed work. I guess I was just not checking the paths and not making sure they were right. I was in fact able to remap the offending top of page command to ALT-PgUp instead, since I rarely ever use that command anyway. Thanks for helping me troubleshoot and debug.
plb
To me, I wouldn't want to spend time trying to figure out why building within 4coder is failing in that particular way, given that building within 4coder isn't going to work anyway (due to the aforementioned dll issue).
Pretty much what you said earlier in the post sums up why it would fail that way. The program is saying "Im not gonna change something I am currently using in memory." :P
Allen, have you considered replacing the bat and sh scripts with a small C program ?
mrmixer
Allen, have you considered replacing the bat and sh scripts with a small C program ?
Yeah I have. I do that for the internal 4coder build stuff. But it won't work very well for buildsuper. The biggest problem here is getting cl in the path, which I would STILL have to do if my build system was a small C program, and so I would STILL have to do that from a script. The other option is to leave that problem up to the user, but that option is also available without switching to the C program.
Besides these scripts are so short that we aren't really dealing with difficulty from the fact that they're duplicated which is the best reason to switch it to C in my opinion.
The problem with bat files for me is that the syntax (or my lack of knowledge of the syntax) makes it hard to make thing works. Last week I wasted some time because the ")" in "program file(x86)" in the PATH closed the IF "scope". Anyway out of curiosity I want to try to make it work.
Isn't there a way to preserve/copy the child process environment with CreateProcess so that we could call vcvarsall.bat from the program and then the cl command ?
I found those but didn't try yet (the answer on stack overflow suggests to pipe "set" after "vcvarsall" to have the environment printed in stdin):
Changing Environment Variables
Get Environment Variables of Child Process in VC++
Isn't there a way to preserve/copy the child process environment with CreateProcess so that we could call vcvarsall.bat from the program and then the cl command ?
I found those but didn't try yet (the answer on stack overflow suggests to pipe "set" after "vcvarsall" to have the environment printed in stdin):
Changing Environment Variables
Get Environment Variables of Child Process in VC++
Unfortunately in my experience BATCH/BASH has been something of a necessary evil. I tried using the c shell on Linux which is supposed to be more like C, but it's not quite there, and the fact that BASH is the lingua franca anyway made the point a bit moot. I suspect that going 100% c is one of those things that has 99% of the effort in closing the last 1% of the gap.