www.digitalmars.com         C & C++   DMDScript  

c++ - precompiled headers problem

reply "W這dzimierz Skiba" <abx abx.art.pl> writes:
Hi!

I'm trying to add precompiled headers support to the bakefiles 
( http://bakefile.sourceforge.net/ ) where dmars makefile and smake are 
already supported. I have a couple of problems. One of the major packages 
supported is wxWidgets toolkit. The build system makes in one make a few 
libraries. They all share directory for objs, for libs for includes. They 
all use one common header. There is need for having separated precompiled 
headers for each lib achieved from the same header in the same directory. 
Do I understand correct from the online DMC site (the page which covers 
precompiled headers) that it's impossible because with -HF I can influence 
name of precompiled header file during writing only? If I fail to 
understand it or I miss some workaround, than I would appreciate any 
helpful comment added to this thread or directly to the patch entry in 
bakefile patch tracker.

http://sourceforge.net/tracker/index.php?func=detail&aid=1043143&group_id=83016&atid=568031
http://sourceforge.net/tracker/index.php?func=detail&aid=1041456&group_id=9863&atid=309863

Thanks in advance for any help, ABX
Oct 08 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
What I prefer to do is create a "total.h" for each project, and make a
precompiled header for it called "total.sym". You can have the compiler
refer to it with the -HItotal.h flag.

"W這dzimierz Skiba" <abx abx.art.pl> wrote in message
news:ck6p8i$258u$1 digitaldaemon.com...
 Hi!

 I'm trying to add precompiled headers support to the bakefiles
 ( http://bakefile.sourceforge.net/ ) where dmars makefile and smake are
 already supported. I have a couple of problems. One of the major packages
 supported is wxWidgets toolkit. The build system makes in one make a few
 libraries. They all share directory for objs, for libs for includes. They
 all use one common header. There is need for having separated precompiled
 headers for each lib achieved from the same header in the same directory.
 Do I understand correct from the online DMC site (the page which covers
 precompiled headers) that it's impossible because with -HF I can influence
 name of precompiled header file during writing only? If I fail to
 understand it or I miss some workaround, than I would appreciate any
 helpful comment added to this thread or directly to the patch entry in
 bakefile patch tracker.


 Thanks in advance for any help, ABX

Oct 08 2004
parent reply "W這dzimierz Skiba" <abx abx.art.pl> writes:
"Walter" <newshound digitalmars.com> wrote in
news:ck7hb3$2o25$1 digitaldaemon.com: 
 What I prefer to do is create a "total.h" for each project, and make a
 precompiled header for it called "total.sym". You can have the
 compiler refer to it with the -HItotal.h flag.

I probably not detailed it enough. The problem is that we do have such file already (at least in wxWidgets). To make it more clearer for you: we have possibility of making library monolithic or multilib. This cause that for several builds common header is single for a few libraries and therefore such headers look different for each lib (because tometimes it serves for bulding dll or interfacing such dll for example) and dependicies look like: all: lib1 lib2 lib1: sym1 obj11 obj12 lib2: sym2 obj21 obj22 sym1: total.h sym2: total.h And now problem raises: if sym1 and sym2 share the same header and the same directory, how can I point to compilation of objs which sym file should be used ? ABX
Oct 11 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"W這dzimierz Skiba" <abx abx.art.pl> wrote in message
news:ckdbh1$p16$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in
 news:ck7hb3$2o25$1 digitaldaemon.com:
 What I prefer to do is create a "total.h" for each project, and make a
 precompiled header for it called "total.sym". You can have the
 compiler refer to it with the -HItotal.h flag.

I probably not detailed it enough. The problem is that we do have such

 already (at least in wxWidgets). To make it more clearer for you: we have
 possibility of making library monolithic or multilib. This cause that for
 several builds common header is single for a few libraries and therefore
 such headers look different for each lib (because tometimes it serves for
 bulding dll or interfacing such dll for example) and dependicies look

 all: lib1 lib2

 lib1: sym1 obj11 obj12

 lib2: sym2 obj21 obj22

 sym1: total.h

 sym2: total.h

 And now problem raises: if sym1 and sym2 share the same header and the

 directory, how can I point to compilation of objs which sym file should be
 used ?

Why not make a total2.h that simply consists of: #include <total.h> and use that for the sym2 precompiled header?
Oct 11 2004
parent reply "W這dzimierz Skiba" <abx abx.art.pl> writes:
"Walter" <newshound digitalmars.com> wrote in 
news:ckdhk2$vp7$1 digitaldaemon.com:

 Why not make a total2.h that simply consists of:
     #include <total.h>
 and use that for the sym2 precompiled header?

Because that would work for multilib version of the build while in monolithic build they still need to use the same header. Also we have well established convenience for building begining of cpp files. http://www.wxwidgets.org/standard.htm#pch #include "wx/wxprec.h" #ifdef __BORLANDC__ #pragma hdrstop #endif Above works with Open Watcom, VisualC, GCC, Borland. Changing it to anything more complicated would be hardly maintained and a lot overcomplicated (and still would solve wxWidgets only while bakefile system is not wxWidgets-only). Any further other suggestion? I'm open to explanations which would lead us to succesfully supprt precompiled headers with DMC. ABX
Oct 11 2004
parent reply "Walter" <newshound digitalmars.com> writes:
I don't understand why you cannot use a total2.h. It needn't be used for the
builds with other compilers. A one line source file doesn't need much
maintenance <g>.

"W這dzimierz Skiba" <abx abx.art.pl> wrote in message
news:ckdumc$1adm$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in
 news:ckdhk2$vp7$1 digitaldaemon.com:

 Why not make a total2.h that simply consists of:
     #include <total.h>
 and use that for the sym2 precompiled header?

Because that would work for multilib version of the build while in monolithic build they still need to use the same header. Also we have well established convenience for building begining of cpp files. http://www.wxwidgets.org/standard.htm#pch #include "wx/wxprec.h" #ifdef __BORLANDC__ #pragma hdrstop #endif Above works with Open Watcom, VisualC, GCC, Borland. Changing it to anything more complicated would be hardly maintained and a lot overcomplicated (and still would solve wxWidgets only while bakefile

 is not wxWidgets-only).

 Any further other suggestion? I'm open to explanations which would lead us
 to succesfully supprt precompiled headers with DMC.

 ABX

Oct 14 2004
parent "W這dzimierz Skiba" <abx abx.art.pl> writes:
"Walter" <newshound digitalmars.com> wrote in
news:ckm7hn$2n3n$1 digitaldaemon.com: 
 I don't understand why you cannot use a total2.h. It needn't be used
 for the builds with other compilers. A one line source file doesn't
 need much maintenance <g>.

Because: 1. There is about 10 libraries so there would be need for total0 ... total9 http://www.wxwidgets.org/manuals/2.5.3/wx_librarieslist.html 2. Bakefile is supposed to be universal tool and is not part of wxWidgets. While I can handle whatever within wxWidgets (as long as other developers agree with it) I cannot force all the projects on ther world to be changed in order to be supported by bakefiles. Bakefile has to be as simple as possible from point of view of the person expected to switch to it. If user says that lib1 has to use precompile header.h and lib2 has to use precompiled header.h too but with different compiler settings than bakefile has to find a way of translating it into native makefile/compiler syntax as perfect as possible. 3. It would make usage of wxWidgets hard from user point of view, because he would not know which header should he use in his own application to benefit from precompiled headers. 4. Additional header seems not necessary with subdirectory method described earlier. ABX
Oct 14 2004
prev sibling next sibling parent reply Jan Knepper <jan smartsoft.us> writes:
Why don't you generate the precompiled header file with:

dmc -cpp $(FLACS) -c -H -HD<precDir> -HO- -I... 
-HF.\<Output>\<precFile>.SYM -o.\<Output>\<precFile>.PCO <precFile>.h(pp)

amd than use it on source files like:

dmc $(FILE.cpp) -cpp -c -H -HD<OutputDir> -HO- -I... 
-o<OutputDir>\$(FILE).obj

Just make sure that the first file included in the source files has the 
name of <precFile.h(pp)

Jan



W這dzimierz Skiba wrote:
 Hi!
 
 I'm trying to add precompiled headers support to the bakefiles 
 ( http://bakefile.sourceforge.net/ ) where dmars makefile and smake are 
 already supported. I have a couple of problems. One of the major packages 
 supported is wxWidgets toolkit. The build system makes in one make a few 
 libraries. They all share directory for objs, for libs for includes. They 
 all use one common header. There is need for having separated precompiled 
 headers for each lib achieved from the same header in the same directory. 
 Do I understand correct from the online DMC site (the page which covers 
 precompiled headers) that it's impossible because with -HF I can influence 
 name of precompiled header file during writing only? If I fail to 
 understand it or I miss some workaround, than I would appreciate any 
 helpful comment added to this thread or directly to the patch entry in 
 bakefile patch tracker.
 
 http://sourceforge.net/tracker/index.php?func=detail&aid=1043143&group_id=83016&atid=568031
 http://sourceforge.net/tracker/index.php?func=detail&aid=1041456&group_id=9863&atid=309863
 
 Thanks in advance for any help, ABX

-- ManiaC++ Jan Knepper But as for me and my household, we shall use Mozilla... www.mozilla.org
Oct 11 2004
parent reply "W這dzimierz Skiba" <abx abx.art.pl> writes:
Jan Knepper <jan smartsoft.us> wrote in
news:ckea3m$1l4g$1 digitaldaemon.com: 
 Why don't you generate the precompiled header file with:
 
 dmc -cpp $(FLACS) -c -H -HD<precDir> -HO- -I... 
 -HF.\<Output>\<precFile>.SYM -o.\<Output>\<precFile>.PCO
 <precFile>.h(pp) 

Because I can't find the reference to such usage in the DMC documentation. I know you have adviced this in the past too but still only the syntax I mentioned earlier was documented. Bakefile is supposed to exist for years, using hack for it risks that the reason for the hack will be forgotten without background in documentation and hard to maintain in case of necessary changes.
 amd than use it on source files like:
 
 dmc $(FILE.cpp) -cpp -c -H -HD<OutputDir> -HO- -I... 
 -o<OutputDir>\$(FILE).obj

And moreover this makes the same problem, I do not see where I can select name of the *.sym file in case of a few *.sym files available in directory and all of them were made from the same .h file but with different flags of the compiler. I think the only way of workaround for it will be to use separated subdirectories for each of the sym files. ABX
Oct 12 2004
next sibling parent reply Jan Knepper <jan smartsoft.us> writes:
 Because I can't find the reference to such usage in the DMC documentation. 
 I know you have adviced this in the past too but still only the syntax I 
 mentioned earlier was documented. Bakefile is supposed to exist for years, 
 using hack for it risks that the reason for the hack will be forgotten 
 without background in documentation and hard to maintain in case of 
 necessary changes.

This is how the IDDE does it... I think it will be supported as I do not expect that Walter wants to break communication with the IDDE at this moment. Also, documenting is should not just be a matter of the "tools" document, but also inside the Bakefile.
 And moreover this makes the same problem, I do not see where I can select 
 name of the *.sym file in case of a few *.sym files available in directory 
 and all of them were made from the same .h file but with different flags of 
 the compiler.

No it does not... The <Ouput> directory is the place where the intermediate files go for a certain build. A certain build uses particular flags which obviously generates difference code. So when invoking the compiler with difference flags and may be even difference #defined such as -D_DEBUG it might be a very good idea to write all output files into a separate directory and make sure the pre-compiled header is placed into this same directory and read from this directory.
 I think the only way of workaround for it will be to use separated 
 subdirectories for each of the sym files.

That's exactly what I am getting at, I would use that subdirectory for the complete compiler output of intermediate files such as .sym, .pco, .obj, etc. Jan -- ManiaC++ Jan Knepper But as for me and my household, we shall use Mozilla... www.mozilla.org
Oct 12 2004
parent "W這dzimierz Skiba" <abx abx.art.pl> writes:
Jan Knepper <jan smartsoft.us> wrote in
news:ckgod3$o44$1 digitaldaemon.com: 
 This is how the IDDE does it...
 I think it will be supported as I do not expect that Walter wants to 
 break communication with the IDDE at this moment.

I see, thanks.
 Also, documenting is should not just be a matter of the "tools" 
 document, but also inside the Bakefile.

I'm not sure I understand that part.
 And moreover this makes the same problem, I do not see where I can
 select name of the *.sym file in case of a few *.sym files available
 in directory and all of them were made from the same .h file but with
 different flags of the compiler.

No it does not... The <Ouput> directory is the place where the intermediate files go for a certain build. A certain build uses particular flags which obviously generates difference code.

But "certain build" of wxWidgets creates a few libraries and all of them have different flags passed to the same header. It is not only debug/unicode flags, but also about interfacing rest of files as being external vs. internal.
 I think the only way of workaround for it will be to use separated 
 subdirectories for each of the sym files.

That's exactly what I am getting at, I would use that subdirectory for the complete compiler output of intermediate files such as .sym, .pco, .obj, etc.

Meantime I have updated patch tracker in bakefile with new (still incomplete) version of the patch witch should use documented part of precompiled headers usage and needs only further tweaking on bakefile side. Thanks for your support, ABX
Oct 12 2004
prev sibling parent reply chris elliott <biol75 york.ac.uk> writes:
W這dzimierz Skiba wrote:
 Jan Knepper <jan smartsoft.us> wrote in
 news:ckea3m$1l4g$1 digitaldaemon.com: 
 
Why don't you generate the precompiled header file with:

dmc -cpp $(FLACS) -c -H -HD<precDir> -HO- -I... 
-HF.\<Output>\<precFile>.SYM -o.\<Output>\<precFile>.PCO
<precFile>.h(pp) 


that <precfile>$(CORELIB).sym etc might be possible ? chris
Oct 13 2004
parent "W這dzimierz Skiba" <abx abx.art.pl> writes:
chris elliott <biol75 york.ac.uk> wrote in 
news:ckimld$2ej9$1 digitaldaemon.com:
 I've not had time to look at the patch yet, but I would have thought 
 that <precfile>$(CORELIB).sym etc might be possible ?

Yes and no. Yes, it seems possible to put it int -HF during creation of .sym file. No, it seems not possible (as far as documented options are discussed) to put it into compiling of obj file that it should use <precfile>$(CORELIB).sym and not <precfile>$(ADVLIB).sym. Perhaps compiler is able to select it automagically but then what could be a key for this automagic if both .sym files were created from the same .h file. Anyway as I said I decided meantime to workaround it to use subdirectory in the form $(BUILDDIR)\$(CORELIB)\wxprec.sym and appropriate -HD flag. I only wait for Vaclav hints about other issues related to further development of it. ABX
Oct 13 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
There's a new switch for this in the 8.42.1 beta. -Walter
Oct 22 2004
parent "W這dzimierz Skiba" <abx abx.art.pl> writes:
"Walter" <newshound digitalmars.com> wrote in 
news:clbl2s$nbi$4 digitaldaemon.com:

 There's a new switch for this in the 8.42.1 beta. -Walter

Thank you very much! I will test it ASAP. ABX
Oct 25 2004