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.


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



  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


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 ?


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


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 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) 


 


I've not had time to look at the patch yet, but I would have thought 
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