Repo renaming compiler folders

[SMcNeill]

But what happened to the development builds? - 145MB 7z, with nearly 30000 files each (32/64)?

Oh, after a closer look, it seems both archives deliver both compiler versions (mingw32/64), one of it is renamed to c_compiler (according to version), but instead deleting the other one, it remains in place. Is this intended or a glitch in the build process?

I mean I could live with it in the development builds, but later in the release archives it should definitly strip out the unused compiler distibution.

PS - talking about the windows archives...

These two folders have been there forever (or at least for several versions now) with windows, and they've always been kind of a PITA with github.  If you clone the repo with github, you get both directories.  Once you decide to "setup_win.bat". the setup determines if you have a 32-bit or 64-bit OS and then moves and renames the proper folder to become the c_compiler.

The problem with this is if you now open github, it tells you that thousands of files have changed and it wants to sync those changes into the repo.  The only way to eliminate this glitch is to copy the folder and place it back so that github will see those files where it expects to see them, and then it won't consider them to be deleted and altered from the current repo version.

I've mentioned the fix to this before -- and simply adding the files to the .gitignore won't help as they're already in there.

.gitignore:

Code: [Select]

internal/c/c_compiler
internal/temp*
*.o
*.a
*.exe
*.bas
internal/config*.txt
internal/config.ini
internal/help
internal/version.txt
tempfoldersearch.bin
internal/c/mingw32
internal/c/mingw64
internal/c/qbx[2-9].cpp
*.ttf
/run_qb64.sh
/qb64

The files were archived and become part of the repo BEFORE the gitignore file was created.  From reading up on various documentation across the web, this is what needs to happen:

1) remove those references from gitignore
2) remove those directories completely from the repo
3) push the changes to the repo
4) add those ignore references back into the gitignore, so the repo will ignore tracking changes to them.
5) push that change into the repo
6) add those directories back into the repo. 
7) Push that change back to the repo.

This will fix the issues with the files/directories being in the archive before the ignore, and fix the issue with gitignore not actually ignoring the files as the folder won't have existed prior to the addition to the ignore list.  The ignore  list needs to exist before whatever it's ignoring does.

Here -- screenshots of what I'm talking about:

A fresh clone of the repo
  [ You are not allowed to view this attachment ]  

Going through the build process
  [ You are not allowed to view this attachment ]  

Loading Github Desktop once more
  [ You are not allowed to view this attachment ]  


As you can see, gitignore isn't ignoring the loss of those files at all.  The only way to make git happy is to copy the c_compiler back into place as a mingw64 folder that just takes up room and is never used for anything -- which is a complete PITA.

If you guys DO decide to change the setup script so that it deletes the unused folder, PLEASE take the time to fix the gitignore issue as I mentioned above, or else it's going to be a complete and utter PITA to have github redownload those missing files every time someone syncs to an updated version of the repo after having ran the setup script.

[FellippeHeitor]

https://github.com/QB64Team/qb64/issues/213

[FellippeHeitor]

Also, you shouldn't be using setup_win.bat if you're in a development session. Here's the setup script I use, which won't cause the issues you're pointing out. Feel free to use it too: https://gist.github.com/FellippeHeitor/88b149784efdfd747e1a703af6bd57bc

[FellippeHeitor]

Of course you can also remove the color commands in the batch file, as they're not required for compilation 😉

[SMcNeill]

Also, you shouldn't be using setup_win.bat if you're in a development session. Here's the setup script I use, which won't cause the issues you're pointing out. Feel free to use it too: https://gist.github.com/FellippeHeitor/88b149784efdfd747e1a703af6bd57bc

It still has the same issues:

Code: [Select]

reg Query "HKLM\Hardware\Description\System\CentralProcessor\0" | find /i "x86" > NUL && set MINGW=mingw32 || set MINGW=mingw64
echo Using %MINGW% as C++ Compiler
ren %MINGW% c_compiler
cd ../..
It's renaming the mingw directory to become the c_compiler directory.  Github then wants to find and restore the missing mingw files, as they're no longer where it saw them last.

As long as those folders are just going to be renamed, then github is going to be crying foul over them not being where they're supposed to be.  They need to be removed, added to gitignore, and then added back into the repo.  That's all it'd take to correct the issue.

[RhoSigma]

Well that's indeed a pro to keep it in the repo as is, but why must the unused mingw folders retain in the development build archives? They are delivered completly setup and ready to use, it's not a local clone of the repo in GitHub Desktop, which you mess up when running the setup script.

We should distinguish here between our repo (where we developers work) and the releases (dev/stable) made for the ordinary user, who doesn't care about QB64 development and what's in the repo. A pure user usually want compact packages with as less as possible files and not 30000 from which 25000 are never used or even touched.

PS - Jesus, you guys are so fast :) consider this to be posted right as the first reply after Steve's initial post...

[FellippeHeitor]

Well that's indeed a pro to keep it in the repo as is, but why must the unused mingw folders retain in the development build archives? They are delivered completly setup and ready to use, it's not a local clone of the repo in GitHub Desktop, which you mess up when running the setup script.

Still expecting a reply from Luke, as he may have changed something recently.

[FellippeHeitor]

That's all it'd take to correct the issue.

All I know is we're not touching that before Luke chimes in.

[RhoSigma]

All I know is we're not touching that before Luke chimes in.

Don't worry, I'll do hell and rather keep my hands of the build process :), now that I know what's the (possible) thought behind it, I simply delete the folder(s). It's not just the unused mingw folder but also several others from the actually used (c_compiler) folder, after that I'm down to 5910 files in 296 folders and everything still works as expected. Probably ther's even more stuff we don't really need to use QB64 and compile our programs.

[SMcNeill]

All I know is we're not touching that before Luke chimes in.

And that's the same response from a few years ago, which is why every time I clone a fresh copy of the repo, I still have to copy those renamed folders back over each time.

Since it's a Windows-only issue (Linux and Mac use g++ from wherever its package is installed on your system), it's not one you or Luke deal with a lot, so it always gets shuffled into the "we're not touching it now" pile.  I just thought I'd mention it again so a change to the setup.bat file won't delete the extra, unneeded, folder and add to the hassle of having to be redownloaded after every setup. ;)

[FellippeHeitor]

https://github.com/QB64Team/qb64/issues/213

As indicated, it's in the works.

[FellippeHeitor]

For regular users following this thread: if you don't clone the git repository, but simply download QB64 as usual, none of the folder renaming above will bother you for now, so keep calm.