↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → "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?
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓
← → 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
↑ ↓ ← → "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
↑ ↓
← → "Walter" <newshound digitalmars.com>
writes:
There's a new switch for this in the 8.42.1 beta. -Walter
↑ ↓ ← → "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
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next