Author
Topic: Auto Rebuild Not Working (Read 601 times)

Codeblocks was fine for a few weeks but I'm now having to rebuild the entire project in order for code to run.

Build & Run no longer properly builds, it just runs the last settings.

I'm currently studying tutorials online, & keeping notes as separate progs. I right-click the files properties in the projects window &turn off the compile & link (not on target, only the main options at top). This workflow has been working fine for 50 tutorials or so up until this morning. The build is returning no errors.

I uninstalled Codeblocks via the windows control panel & have reinstalled a newer version several times.

No errors, the build logs are showing a lot of different default paths; compilers & the like, but no errors.

I would guess that build & run needs another setting ticked. It doesn't seem to be building/ updating the linker to my most recent changes which have been made in the projects panel.

EDIT1 - If I make changes to the file then these changes are reflected in my built & run file (provided that file was the last to have it's "compile" & "link" properties ticked in the Projects pane window. However - once I've finished editing that file, turn the compile & link properties off on that file. Go to another file & turn it's compile & link options to selected. That file will not be built or linked. I will see the old file in the output.

If i hit rebuild then my most recent file will be built/ linked.

EDIT2 - Noticed in virtual folders when selecting rename the automatically generated filename text (to rename) is ending with a \ character. I wonder if there's a bug that's adding these after the file has been created/ renamed. If you try to save the virtual folder again then it warns you that you can't have a backslash in the filename; this is clearly a bug.

So your exact steps are:1) Start codeblocks2) Open a project3) Select one file, tick "compile" and "link" in File->Properties->Build4) Build the file with the yellow button in the tool bar5) Run the file with green arrow6) All works7) Remove the tick in "compile" and "link" in File->Properties->Build Open a other fiel9) set there the ticks in "compile" and "link" in File->Properties->Build10) Build with the yellow buttin11) Hit the run button12) The old executable is run

Are this steps correct? If not, can you please describe your process with as many steps as possible?Also it would be nice if you could add a build log for every build you make. Please add them in code tags (# symbol int the new post editor) And please post them from the "Build Log" tab and not from the "Build messages" tab

1 - Thanks for your rapid responses Blue, your exactly right with my stages, well actually I'm hitting build & run, but I'd eat my hat if Build & Run isn't just combining both of these procedures. I just ran 3 different times, oddly the second time worked, but my process was the same & has been the same for 50 or so files. Please don't think this is someone who can't be bothered.

2 - Yes it's an unusual way of working, I'm learning C++ following tutorials from a Youtube channel. It's great to have all of my notes and progs in a single place for reference when I get coding. This process has been working fantastically up until tutorial 43 or so, & my process has been the same each time.

Please post again the build logs, but after hitting the rebuild button.

Generally the best way is to use a project per main function... It is not more work for you to do, contrary, it is less work, because for switching main, you hast have to double click on the project...

The second best way is to use different build targets for every main:Project->Properties->Build target-> Add or dublicate.Select the new target name from the list on the left, and then select the single source file with your main from the "Build target files"Then if you want to build the project select it from the drop down menu near the build button in the toolbar. Or you go to Build->Select->Target

Only the third and most error prone and not convenient way is your way...I think the problem is this:Codeblocks decides to build a file on the timestampIf your exe is from 14:55 and your source (exactly the object) file is from 14:40 the exe will not be rebuild. Also if you switch source file...But to get an idea what is going on we need a full build log for every step you take...(I personally think the output log of codeblocks build process is not verbose enough to easily debug this kind of things...)

Also remember, you can have multiple projects in one folder... so you do not have to make multiple folder and main.cpp files.You can simply create all projects in one folder and call the Projects"Tutorial1.cbp" and the main.cpp file you call "tutorial1.cpp"C++ and codeblocks is not like in java or python or other languages, where the file path is part of the program (what an idiotic idea in the first place...)

I read this thread twice; and, I see nowhere that the Code::Blocks version is stated.

What version of C::B is having this problem?17.12, 20.03 or ?

I see posts like this all the time in where I'm a member of many forums - "what version". Never have I seen a problem solved relating to the current version. Given that patches are very minor tweaks & the issue stated here is obviously related to a global preference setting. Usually I never see anything more constructive from the person requesting versions. They often chime in requesting every possible piece of info being requested about the programme, then nothing whatsoever to solve the problem.

Given that this was happening to my previous version before the update; which was considerably old (ver 17 something previously) it is most certainly not to do with a version. We're obviously talking about a global setting. I'm tempted to force rebuilding on the entire project, but obviously I shouldn't have to do this.

Thanks Blue. Yes I'm not too familiar with IDE's & thanks for your advice. I played a little with Dreamweaver in the past but I'm not really too worried about the IDE atm. I've come to Codeblocks because Visual Studio is way too complicated for me at this stage. Nonetheless there is a problem here regardless of methodology.

Further to your request I changed file prefs to not compile & link & chose a new file. Set that to compile & link & the file was not changed in the output. It was still running the old file. This is the build log below.

I read this thread twice; and, I see nowhere that the Code::Blocks version is stated.

What version of C::B is having this problem?17.12, 20.03 or ?

I see posts like this all the time in where I'm a member of many forums - "what version". Never have I seen a problem solved relating to the current version. Given that patches are very minor tweaks & the issue stated here is obviously related to a global preference setting. Usually I never see anything more constructive from the person requesting versions. They often chime in requesting every possible piece of info being requested about the programme, then nothing whatsoever to solve the problem.

Given that this was happening to my previous version before the update; which was considerably old (ver 17 something previously) it is most certainly not to do with a version. We're obviously talking about a global setting. I'm tempted to force rebuilding on the entire project, but obviously I shouldn't have to do this.

I updated to Ver 20.03 this morning.

The range of codeblocks versions in the wild is gigantic... There are reports form codeblocks version 9 years old, and there are also nightly builds, that fixed a lot bugs from 20.03 release, , versions with the same version number, but different versions of wxWidgets. versions with the same version number, same wxWidgets version number, but different GTK version, 64bit, 32bit ecc.... it is insane, so the question is really legitimate,

The build log does not look like you are making a rebuild (Build-> rebuild) The blue arrows in the toolbar, but only a build (the yellow, or yellow green button).As i mentioned in the previous post codeblocks checks the dates from the file modification and uses this to decide if he should rebuild the exe.Example:1) You modify a.cpp2) Codeblocks checks a.cpp modification date with a.obj modification date -> a.cpp is newer so rebuild a.obj3) Codeblocks checks a.obj modification date with a.exe modification date -> a.obj is newer so rebuild a.exeNow lets say you switch to b.cpp and disablea.cpp4) Codeblocks checks b.cpp modification date with b.obj modification date -> b.cpp is newer so rebuild b.obj5) Codeblocks checks b.obj modification date with a.exe modification date -> b.obj is newer so rebuild a.exe (note: here is a.exe used because you do not switch targets or project)Now lets switch back to a.cpp without modifications, just a build6) Codeblocks checks a.cpp modification date with a.obj modification date -> both the same, so no rebuild7) Codeblocks checks a.obj modification date with a.exe modification date -> a.exe is newer so no rebuild -> start a.exe (the version you build with b.cpp)

Now if you hit the rebuild button (with the blue arrows) a.obj and a.exe will get deleted and everything should work...(bare in mind, it can get quite complicated, and i may miss something here, so do not pinpoint me here....)

Thanks, yes the permutations of versions would be intense. However given I opened the thread stating I had updated & this was seen in the old version was still seen in the new version is a good indicator the version is not the issue here. I'll eat my hat if when this gets solved it's issue related.

The project was rebuilt. As stated in my prev post the sequence used was accurate, the blue rebuild icon was used; I don't think this would be indicated in the logs I'm providing you with though, this process is not recorded in the log. These logs only show the running of the programme. These logs don't even show what files are included in the output of the file.

Now if you hit the rebuild button (with the blue arrows) a.obj and a.exe will get deleted and everything should work...(bare in mind, it can get quite complicated, and i may miss something here, so do not pinpoint me here....)

Thanks, I imagine there would be time & size checks to see if the files were modified, instead of running complete rebuiilds unnecssarily. Yes rebuilding is resolving the issue, clearly the issue is that Codeblocks is not writing the paths to the file which controls which files should be compiled & linked in the Codeblocks environment. It really isn't that complicated.

EDIT2 - Noticed in virtual folders when selecting rename the automatically generated filename text (to rename) is ending with a \ character. I wonder if there's a bug that's adding these after the file has been created/ renamed.If you try to save the virtual folder again then it warns you that you can't have a backslash in the filename; this is clearly a bug.

Please make a Ticket on Source Forge for this bug, where you explain the steps to reproduce it....

Your workflow is build&run a file --> everything worksDisable the file, enable a other file --> everything worksSwitch back to the first file --> No build is triggered, the old executable is run

One thing i did not understand is, did your workflow worked at one point? Are you sure you did not modified the source file every time before you made a build&run?

As i mentioned earlier codeblocks uses time stamps (and as far as i know ONLY time stamps) of the object files to build the exe file.If your exe is newer then the object file, the object file newer then the source file codeblocks can not detect that he has to rebuild the exe...Modifying what files to compile and link via the file properties dialog is not supposed to trigger a build, because codeblocks does not know what it should rebuild (all, or only a couple files? What files?). In this case the user is supposed to trigger the rebuild manually. Codeblocks does not make any dependency checks for source files (ok, i think it makes header inspection, but that is not that difficult), so it can not detect what it should rebuild and what not...

If you enable/disable one file codeblocks should probably rebuild the whole project....I am not sure if this is a bug or user error...

@Other devs what do you think?

Easy solution:After modifying the build options, add a space and delete it again, save the file and hit build.... This should retrigger a build, because the source file has than a newer timestamp than the object file

[EDIT:] I think we modified the save behavior of codeblocks, so if you make no changes to the source file you can not save it. I think in old versions this was allowed... So you probably saved an unmodified file and this triggered the build process....

Thanks Blue, dear lord this is looking like it's going to be version related; owing an apology to stahta01, & looks I could be eating my hat for dinner this evening .

It's possible that I may have edited the files on each build & run, thus changes were made each time & that would explain the issue. I've just tried setting compile & link to a different file, making changes to that file & seeing if that file was correctly updated to the build/ link paths - sadly it was not.

Sounds like I'm not using the IDE properly, so again my apologies there. I just can't picture a project for each & every tutorial; it's going to be a bit bloated I think, normal programmes have many files & I would think that through the course of development you'll turn them on and off to isolated changes & make it easier to debug; but you know a lot more than myself. Thank you for explaining the process to me & I see the logic in where I'm failing at the moment.

Thanks, your statement in reply # 3 was accurate with the only exception being I was using build & run.

When I say I'm turning the file off in compile & link I mean the pic attached; I'm referring to the top two; which are unticked in the photo; meaning not being run in the IDE.

EDIT - I was using virtual folders in Codeblocks pic attached. I've taken your comments on board & have been playing around with projects, it's so bloated & not really going to be easy to reference each topic in a project, I prefer my old way; as more structured.

Thanks, your statement in reply # 3 was accurate with the only exception being I was using build & run.When I say I'm turning the file off in compile & link I mean the pic attached; I'm referring to the top two; which are unticked in the photo; meaning not being run in the IDE.

Ok, this part is obvious for me, but this part:

Quote

making changes to that file & seeing if that file was correctly updated to the build/ link paths - sadly it was not.

You Modify the file and save the file and then the build also does not work?

Quote

ve taken your comments on board & have been playing around with projects, it's so bloated & not really going to be easy to reference each topic in a project, I prefer my old way; as more structured.

If you want to switch files quickly, use the key combindation ctrl+gIf you want a flat view of the files (then it looks like your virtual folders) Right click on the Project in the Management pane->Project Tree->Categorize by file types

Thanks, your statement in reply # 3 was accurate with the only exception being I was using build & run.When I say I'm turning the file off in compile & link I mean the pic attached; I'm referring to the top two; which are unticked in the photo; meaning not being run in the IDE.

Ok, this part is obvious for me, but this part:

Quote

making changes to that file & seeing if that file was correctly updated to the build/ link paths - sadly it was not.

You Modify the file and save the file and then the build also does not work?

Thanks, sorry I think this is a user error. I think the issue is when a new file is created & run directly from the source folder I hadn't experienced these issues.You've understood the above in a previous post, see the second screenshot in relation.

Many thanks for your help, there doesn't seem to be a "resolved" button on this forum, if there was I'd hit it, my thanks again.