User forums > Nightly builds

The 22 february 2006 build is out.

<< < (3/5) > >>

orefa:

--- Quote from: killerbot on February 23, 2006, 11:10:39 pm ---are these headers part of the project (so they show up in the project tree) ?? or are they include in project code, but the header is actually not specified in the project itself ??
--- End quote ---
They are part of the project. Headers that are not listed in the tree would not be saved even in the RC2 version, but now it does not seem to matter if they are in the project or not, they are not saved when the corresponding .cpp file is compiled. They are saved when the full project is build. It's only with compilation of an individual .cpp file that it's a (lesser) problem, but still a bit annoying.

TDragon:
Sorry it took me so long to get back (issues with corporate website and a DNS server), but here are:
cb-ansi-20060223-r2062.zip from this morning's build, and
wxmsw26_gcc_custom.zip from whenever I last built wxWidgets.

killerbot:

--- Quote from: orefa on February 24, 2006, 12:02:17 am ---
--- Quote from: killerbot on February 23, 2006, 11:10:39 pm ---are these headers part of the project (so they show up in the project tree) ?? or are they include in project code, but the header is actually not specified in the project itself ??
--- End quote ---
They are part of the project. Headers that are not listed in the tree would not be saved even in the RC2 version, but now it does not seem to matter if they are in the project or not, they are not saved when the corresponding .cpp file is compiled. They are saved when the full project is build. It's only with compilation of an individual .cpp file that it's a (lesser) problem, but still a bit annoying.


--- End quote ---

ok, that could be, yesterday O tried it myself and it worked well, but I builded a project. Not just a single .cpp file.
Well, we have different angles of view at this :
1) I have adjusted my file1.h and I want to compile my test2.cpp which does NOT include, (also not through other headers) file1.h  -> do I really want to have file1.h saved, maybe it is not even in a state where it would compile cleanly ( this argument can also be applied on project build, so I think it is a weak argument, certainly on project level) ??
When you build a project, it checks all files belonging to the project to see if they need saving

2) I have adjusted file1.h and file1.cpp (which in includes file1.h) is going to be compiled, (this is the case you say it does not save it (I did not check this yet)) -> would be nice to save it, we need to break this up in several sitations :
 - both files belong to the project (so the regular project search can be used -> easy)
 - the header files does not belong to the project, could check all include paths for modified files, this will sure make everything much slower, don't like it, so no more info on this one ;-)
 - the cpp file does not belong to the project (header can or can not belong to it), then there's no project to have it's files checked (could check the local directory where the file resides, but here also, don't like it ...)

So in my personal opinion, the situation where both belong to the project, it might be a good addition to have a 'project'-check for files to save action.

I will try to have a look at this, this weekend.

orefa:

--- Quote from: killerbot on February 24, 2006, 02:03:35 pm ---- both files belong to the project (so the regular project search can be used -> easy)
[...]
So in my personal opinion, the situation where both belong to the project, it might be a good addition to have a 'project'-check for files to save action.

I will try to have a look at this, this weekend.
--- End quote ---

Yes, this is exactly right. It's the only case of single-file compilation where a check would be both expected and convenient. Thanks for looking into it!

boaz:
I'm not sure if this is old problems or not

1. symble search - Go to the symbles tab put a search term like "WXDLLIMPEXP_XML" press "-->". Boom C::B will crash.
OK I rechecked this happens only when you have files with ..\..\ type paths in your project (see below) once I have C::B compiling again I'll try to fix it.

2. Breakpoints Dialog - No remove, no right-click no nothing a list and thats it. Now looking in the code (SVN from 22/2/2006) for "breakpointsdlg.cpp" I see all these things in code. what plugin was included in the build?

If At it I have some Questions:

1. a C::B project for wxWidgets - I try to build an external make project for the <WX>\build\makefile.gcc. Now since I can't specify a working folder for the Make command, and since I don't even want to begin on adding Files to a project from ..\..\ folders. (Try right-click "open #include <wx/wx.h> " for just the begining of the problems with that). So I made a msw.Makefile at root folder that with an m.bat will run the build/msw/makefile.gcc, on all the right targets.
This all works well but on the Build-Messages the paths to compilation errors/warnnings are of the form "../../include/wx/log.h" : 55. Needless to say that C::B has hard time finding the files on double click.
Is there a switch to GCC that tells it to output full-paths to files instead of relative paths. I was looking in gnuc.org but could not find anything.

Navigation

[0] Message Index

[#] Next page

[*] Previous page