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

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³odzimierz 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

"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

"W³odzimierz 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?

"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

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³odzimierz 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

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

> 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

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

W³odzimierz 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