Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Precompiled headers (PCH) support in Code::Blocks

<< < (5/8) > >>

MortenMacFly:
Dear Devs,

first of all I didn't know whether to put tjhis in here (because it is related to these changes) or in the Fortran77 thread. However: I thought I let you know:

I found out that luckily (!) the the latest changes enabled the "full" Fortran (77) support via Code::Blocks! How to attach the G77 compiler has already been discussed, hence there was this problem loosing the "compile" and "link" flag for Fortran files. Thus they had to be enabled manually every time the project was re-loaded. The following changes in the code (which is taken from the current CVS branch) lead to the flags being restored "correclty" also for non-C/C++ files:


--- Code: ---// FileType ft = FileTypeOf(filename);
    localCompile = compile;// &&
// (ft == ftSource ||
// ft == ftResource);
    localLink = link;// &&
// (ft == ftSource ||
// ft == ftResource ||
// ft == ftObject ||
// ft == ftResourceBin ||
// ft == ftStaticLib);

--- End code ---

The file-check (not including Fortran source code files) has gone.

To sum up: To enable Fortran (77) support one is required to:
1.) add the G77 compiler (just make a copy of GCC and replace the gcc compiler/linker with g77)
2.) add the Fortran file types (Project->Project tree->Edit file types & categories)
3.) enable "compile" and "link" options for the Fortran source files
...and you're done.

Works very well for me!!!

Thanks - that's making my life a lot easier!

With best regards,

Morten.

mandrav:
Glad it works for you Morten :)

On another note, the autotools build system used to build C::B under non-windows platforms, is now supporting precompiled headers. Set with --enable-pch. The feature is enabled by default and is only used if the compiler really supports it.


--- Code: ---time make

<...build log snipped...>

real    5m7.585s
user    4m10.873s
sys     0m42.310s

--- End code ---

rickg22:
Question - shouldn't the gen_pch.bat be added to CVS?
BTW, the MinGW path should also be in an environment variable.

*Update*

Just rebuild the entire project. On my Athlon XP 1800+ it took 6 minutes, 58 seconds. Impressive :)

Now I have a question. If I change one of the headers, i'll have to generate the PCHs again, right?

I was wondering, if with the new dependencies stuff we could be able to make a separate Target (PCH) that consists of an MS-DOS command (the batch file) and depends on all the headers? Can it be done?

Urxae:

--- Quote from: rickg22 on October 20, 2005, 06:30:57 am ---Question - shouldn't the gen_pch.bat be added to CVS?

--- End quote ---

That might cause problems as it might be different for everyone (hardcoded paths), and CVS would try to version it. Maybe add a gen_pch.bat.template and have everyone copy and edit it locally.


--- Quote ---BTW, the MinGW path should also be in an environment variable.

--- End quote ---

Actually, it shouldn't be necessary at all, MinGW automatically adds that path at the end of the include path list.

mandrav:

--- Quote from: rickg22 on October 20, 2005, 06:30:57 am ---Question - shouldn't the gen_pch.bat be added to CVS?
BTW, the MinGW path should also be in an environment variable.

--- End quote ---

Not really... This batch should be created and used by those who want to enable PCH support before RC2.


--- Quote from: rickg22 on October 20, 2005, 06:30:57 am ---Now I have a question. If I change one of the headers, i'll have to generate the PCHs again, right?

I was wondering, if with the new dependencies stuff we could be able to make a separate Target (PCH) that consists of an MS-DOS command (the batch file) and depends on all the headers? Can it be done?

--- End quote ---

Now that you 've built the latest C::B, the project file contains everything needed to rebuild the PCHs automatically if they change. No need for external batch files or anything. C::B is now PCH-aware ;) (for gcc, that is)

Navigation

[0] Message Index

[#] Next page

[*] Previous page