Recent Posts11
Using Code::Blocks / Re: new project wizard fails to locate glfw3.h
« Last post by Vigor on April 21, 2024, 11:45:32 pm »So, I loaded up the default 20.03 version of codeblocks, intending to copy its wizard and paste it into notepad but the wizard it showed was the same as the nightly build wizard
except there were a few more options when I right clicked to edit it.
Among the options were...
-a warning that the script had been edited and was stored globally in my local user directory (or something like that i can't see it any more)
-an option to delete the modified script
I deleted it and then was able to start a new glfw project which worked/built/linked properly. I can then modify that project to work with glfw3.
So, I suppose my problem is solved. I have found a workaround that allows me to make new projects that link and build correctly.
But, the strange thing is, when I then load up the nightly version of codeblocks it won't allow me to create new projects that build/link even with the old script. It will make a new project and it will be a glfw project, that project just won't build/link. However,
I meddled with project build options and by changing the working directory or adding working directories I could make some of the error messages go away. But as soon as one error went away a new error showed up. I was not able to find a directory or combination of directories which made everything work.
Also, I'm not sure why but I tried to change the compiler. It appears i have 3 compilers so I tried them all. GCC Default and GCC MinGW compiler produced the same errors i think. GCC MinGW64 compiler produced only one "error" - cannot find -lglfw3: No such file or directory. I don't even know what lglfw3 is. It doesn't even show an extension and AFAIK there shouldn't be an lglfw3 anything.
Final thoughts...
-i think i liked the 20.03 problems more than the nightly problems
-when I had the original problem of not being able to find glfw3.h, i felt like I needed to lie to the wizard when it asked what the path to glfw3.h is. Specifically the path to the glfw3.h was c:/program files/codeblocks/mingw/include/glfw3/glfw3.h but in order to give the wizard what it wanted rather than what it asked for I had to put the path as c:/program files/codeblocks/mingw/ and guess at where the file actually needed to be. Changing the path I supplied to the wizard to the actual path would make everything else fail to work.
-I think spreading files around to a bunch of different directories is asking for trouble. If for whatever reason it seems important to quarantine glfw3 files, why not quarantine them all in the same place. But is there a reason to quarantine them? Why not put all .h's in an include folder, all .a's in a lib folder etc. Or why have a bin folder with the executable rather than putting the executable right next to the project file so there would be no need for a working directory? The more directories there are the more potential there is for problems imho opinion. I don't contend to be on the same level of programming ability as the devs of codeblocks but I try to keep things simple. I can only wrap my head around so much complexity.
except there were a few more options when I right clicked to edit it.
Among the options were...
-a warning that the script had been edited and was stored globally in my local user directory (or something like that i can't see it any more)
-an option to delete the modified script
I deleted it and then was able to start a new glfw project which worked/built/linked properly. I can then modify that project to work with glfw3.
So, I suppose my problem is solved. I have found a workaround that allows me to make new projects that link and build correctly.
But, the strange thing is, when I then load up the nightly version of codeblocks it won't allow me to create new projects that build/link even with the old script. It will make a new project and it will be a glfw project, that project just won't build/link. However,
I meddled with project build options and by changing the working directory or adding working directories I could make some of the error messages go away. But as soon as one error went away a new error showed up. I was not able to find a directory or combination of directories which made everything work.
Also, I'm not sure why but I tried to change the compiler. It appears i have 3 compilers so I tried them all. GCC Default and GCC MinGW compiler produced the same errors i think. GCC MinGW64 compiler produced only one "error" - cannot find -lglfw3: No such file or directory. I don't even know what lglfw3 is. It doesn't even show an extension and AFAIK there shouldn't be an lglfw3 anything.
Final thoughts...
-i think i liked the 20.03 problems more than the nightly problems
-when I had the original problem of not being able to find glfw3.h, i felt like I needed to lie to the wizard when it asked what the path to glfw3.h is. Specifically the path to the glfw3.h was c:/program files/codeblocks/mingw/include/glfw3/glfw3.h but in order to give the wizard what it wanted rather than what it asked for I had to put the path as c:/program files/codeblocks/mingw/ and guess at where the file actually needed to be. Changing the path I supplied to the wizard to the actual path would make everything else fail to work.
-I think spreading files around to a bunch of different directories is asking for trouble. If for whatever reason it seems important to quarantine glfw3 files, why not quarantine them all in the same place. But is there a reason to quarantine them? Why not put all .h's in an include folder, all .a's in a lib folder etc. Or why have a bin folder with the executable rather than putting the executable right next to the project file so there would be no need for a working directory? The more directories there are the more potential there is for problems imho opinion. I don't contend to be on the same level of programming ability as the devs of codeblocks but I try to keep things simple. I can only wrap my head around so much complexity.