Auto Save?

[tasdev]

Hi Everyone

New user here! Is there a setting to automatically save any modified files when doing a compile or make?

I am using a recent nightly - July 14 - on debian Linux. I also hope to use this environment on Windows (currently Codewarrior) and Mac (currently XCode and Codewarrior) one day.

Cheers

David

[Pecan]

Hi Everyone

New user here! Is there a setting to automatically save any modified files when doing a compile or make?

I am using a recent nightly - July 14 - on debian Linux. I also hope to use this environment on Windows (currently Codewarrior) and Mac (currently XCode and Codewarrior) one day.

Cheers

David

For nightly builds or SVN versions, files are automatically written to disk before compiling.

There is also an AutoSave plugin to save files on a user timed basis.

[johnfemiani]

I did not get the point of Pecan's respose. I would like the same feature as tasdev;  When I press the 'build' button I want that to trigger the IDE to save all modified files. Visual studio does this and that is a very convenient feature.  Upon switchin to C::B I have found myself scratching my head about why I cant fix a syntax error, only to realize that it had been fixed and not saved, so the compiler was looking at an out-of-date file.   Autosave is nice but I cant _continually_ autosave. I currently have it set to autosave every  5 minutes, but that doesn't really fix my problem.


John

[Biplab]

I did not get the point of Pecan's respose.

What Pecan said is simple. C::B saves all the files to disc before compiling.

I would like the same feature as tasdev;  When I press the 'build' button I want that to trigger the IDE to save all modified files. Visual studio does this and that is a very convenient feature.  Upon switchin to C::B I have found myself scratching my head about why I cant fix a syntax error, only to realize that it had been fixed and not saved, so the compiler was looking at an out-of-date file.   Autosave is nice but I cant _continually_ autosave. I currently have it set to autosave every  5 minutes, but that doesn't really fix my problem.

Can you specify the version you are using?? Because nightly releases have this feature.

Please note that once all the project files are saved to disc, the build process is started. If you edit your files while the build process is active, it won't be saved while compiling and the active build process will use the last saved file instead.

[johnfemiani]

Can you specify the version you are using?? Because nightly releases have this feature.

I use SVN4413.

What Pecan said is simple. C::B saves all the files to disc before compiling.

Visual studio saves ALL modified files, but C::B only saves the ones that are in the project.   Sometimes header files come from a different project, or may not be added to the project at all.   In my case I imported a project which referenced header files from another location which I had to modify.   A quick-fix is just to add all of the other headers to the project, but it would make sense if C::B saved all modified files rather than just the ones that are a part of the active project.


John

[MortenMacFly]

Visual studio saves ALL modified files, but C::B only saves the ones that are in the project.   Sometimes header files come from a different project, or may not be added to the project at all.

Well you don't really want C::B to save whatever files you have opened before compilation?! :shock:
I know that if this would be implemented other people surely will start complaining (and I believe they would be right).
Why don't you just make the project setup correct and tell C::B what files really belong to the project?!
With regards, Morten.

[johnfemiani]

But AutoSave saves all files, ... this is just using the "build" event as a trigger in addition to using the clock.
In VS it is an option (so of course it can be turned on or off) that many I have seen using the IDE have chosen to set. 

The issue is that while one file may use a header file from another, the header file does not really belong to that project.
In my case I am trying to patch somebody elses header file which is indirectly included (it is the implimentation of a template-class).

-- A better option than saving all of the files would be to save all dependancies.

[Biplab]

The issue is that while one file may use a header file from another, the header file does not really belong to that project.
In my case I am trying to patch somebody elses header file which is indirectly included (it is the implimentation of a template-class).

-- A better option than saving all of the files would be to save all dependancies.

The issue could be further complicated. Let's say the included header structure is -

foo.h
 |_ foo1.h
      |_ foo2.h
           |_ foo3.h

In this case let's assume that you've included foo.h. So if you edit foo3.h (which is not part of the project) how C::B would determine that you've edited that or not without parsing the header interdependencies??

Please note that C::B supports multiple compiler and it's not easy to get a parsed output from all the supported compilers.

Rather a better option would be to add foo3.h to your project which will allow C::B to monitor and save it.

-- A better option than saving all of the files would be to save all dependancies.

Add the required header to project. The header will be treated as a dependency.

[johnfemiani]

That is exactly the scenario that I faced; and while the solution you suggest is less-than-elegant it is the one I am choosing to use.

Nevertheless the behavior I suggested is the one that I expected; and the one that the initial poster probably expected as well.   

It seems that the developer response is:

" C::B does not and will not support an option to autosave ALL files on build, and will not support autosaving all DEPENDANT files on build because dependancy tracking is too complex when multiple compilers are in use, and there is a simple workaround by including dependant files in the project."

This is reasonable to me and all of my questions are answered; I did not understand the initial response because I thought "ALL" meant every modified file, but Pecan meant only all modified files in the project.

Cheers,

John



 

[thomas]

You see, Code::Blocks saves all files in a project at build because that makes sense.

Visual studio saves ALL modified files

Yes, but this is plain stupid (not from your part, but from VS). You may have grown to this behaviour because you have been "taught" that this is how it should be by using Visual Studio, but that doesn't make it right.
If something doesn't belong to a project, it should not be affected by a project-related action. Software should never do such things as modifying "random" files behind your back, this is really, really bad, it can lead to desastrous results.

But AutoSave saves all files

This, too, makes sense. The purpose of AutoSave is not to save files. The purpose of AutoSave is to create regular save points of everything you have been working on in case your computer crashes or you lose power, etc. So if you have been working for 6 hours without saving, you will be able to recover that work from the automatic save points.
Of course you might have modified something and never intended to save it, and the application has no way of knowing this. Therefore, AutoSave saves to a backup file and won't touch the original (unless you tell it otherwise).
Thus, you will have both the last saved and the last auto-saved versions of each file in case of a failure.

[johnfemiani]

Thanks for blaming VS and not me  .

However, I checked, and VS actually appears to save only the dependencies (whether they are in the project or not).

The problem is folks have been saying 'ALL' to mean different things;  All in the project or all files that effect the build. These are obviously different things.

Second, I think saving or ?prompting? to save dependant files would actually be smart, and that is my own opinion. If you have changed a file in your text buffer it is an easy mistake to expect that when you compile it will reflect those changes.  If you can not easily track dependencies I understand though.

However, if a compiler error refers to a line number and I click on it, it is not good at all for C::B to jump to a modified line in an unsaved buffer.  You have to stay on your toes to notice the asterisk in the caption. 

I have been using C::B for just a couple of days, so I am a novice user, but I have spent longer than I like to admit wondering why syntactically correct code was flagged as a syntax error by g++.  Those familiar with C::B may find it trivial, but I am sure I am not the only one who has stumbled over this.

John

[Biplab]

The problem is folks have been saying 'ALL' to mean different things;  All in the project or all files that effect the build. These are obviously different things.

And thanks for blaming the helpful folks, too. Were you clear with your question in the beginning??

However, I checked, and VS actually appears to save only the dependencies (whether they are in the project or not).

As Thomas said, this is a plain stupid feature of VS. My included file could stay anywhere in the world and it may be in the nth level of dependency tree. So just because I opened that file in any editor or even in C::B and changed it, C::B should hunt for that file which I've just edited and not saved !!!

Instead of writing thousands of lines of code to support such feature, I'd take the simpler path. I'll add it in my project.

[thomas]

Imagine the following happens:
You are working on project B when you remember that you have some code in project A that you could reuse. You open the corresponding file, but you see it doesn't fit 100%. No problem, you make some changes, copy the code, and paste it into project B. Half a year later, you work on project A again, but you notice it doesn't work any more because someone overwrote your sources. Good job you don't have a backup, either, and you can't remember what modifications you made 6 months ago.

Or, imagine this:
You have a system header open because you wanted too look up some function's declaration, or whatever. You forget about it, and while you're working, you do a multi-file search+replace.
As it happens, this replaces something in your system header too, but you don't even know (because you hit the "All" button on the first hit).
You try to build your project, and it fails, and you have no darn idea why. Sure enough, you can download the system headers again, copy a pristine header to your include dir, and everything works again. However, with any luck, you waste 6 hours of searching for a stupid error that won't go away, and you just don't see why.

There are countless examples like this that could be enumerated. Modifying files that don't belong to a project is just evil.

[johnfemiani]

   I did not mean to "blame" anybody ...  I was trying to point out the original point of confusion.
One person meant something, and another person meant something completely different. The _developers_ on this forum seem to be very consistent but I think the first poster was referring to the VS-style autosave. I appreciate all of the rapid feedbeack this forum gets and I certainly dont want to upset anybody.

I am not convinced by your example because system files should be read-only.  Not realizing you had replaced an item in the file and pressing "Save All" could inadvertantly make the same change.  At least one extremely popular IDE that many C::B newbies may be migrating from uses the autosave-dependacies options with much success.

I am willing to end my discussion on this thread now because I think we all understand the issue and have establised our opinions on it.

[Biplab]

One person meant something, and another person meant something completely different. The _developers_ on this forum seem to be very consistent but I think the first poster was referring to the VS-style autosave. I appreciate all of the rapid feedbeack this forum gets and I certainly dont want to upset anybody.

I guess you are right. The first poster may be interested in VS style auto-save. But we've explained why we feel such feature is not welcome in C::B. So I'm not repeating them.

You'll find such unnecessary features in most of the commercial programs which consumes a huge amount of processing power. A commercial vendor needs such features to justify the Huge Upgrade Price, Huge Hardware Requirement (2GHz CPU, 1GB RAM, 2-3 GB HDD). The upgrade price also includes fixes of some bugs left in previous version. And all these resources are utilised, sometimes, to generate a simple 10 KB exe.

But our goal is quite different.