How are boost/mpl/aux_/preprocessed files generated?
I see in libs/mpl/preprocessed/pp.py there's: self.output.write( \ '\n%s\n' \ '// Preprocessed version of "%s" header\n' \ '// -- DO NOT modify by hand!\n\n' \ % ( self.copyright, match.group(1) ) ) and I've tried to understand from the rest of the *.py how to do it, but I would be a lot easier with some guidance from the authors. What I need to do is change: vectorX_c< T,C0 > to: vectorX_c< T,T(C0) > for each X=1... This would allow the use of an enumeration for C0. TIA.
Larry Evans <cppljevans@cox-internet.com> writes:
I see in libs/mpl/preprocessed/pp.py there's:
self.output.write( \ '\n%s\n' \ '// Preprocessed version of "%s" header\n' \ '// -- DO NOT modify by hand!\n\n' \ % ( self.copyright, match.group(1) ) )
and I've tried to understand from the rest of the *.py how to do it, but I would be a lot easier with some guidance from the authors. What I need to do is change:
vectorX_c< T,C0 >
to:
vectorX_c< T,T(C0) >
for each X=1...
This would allow the use of an enumeration for C0.
In libs/mpl/preprocessed/ do python preprocess.py And it should tell you everything you need to know. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 06/10/2005 01:07 PM, David Abrahams wrote:
Larry Evans <cppljevans@cox-internet.com> writes: [snip]
authors. What I need to do is change:
vectorX_c< T,C0 >
to:
vectorX_c< T,T(C0) >
for each X=1... [snip] In libs/mpl/preprocessed/ do
python preprocess.py
And it should tell you everything you need to know.
Thanks David. This gave me: <----- cut here ----- Usage: preprocess.py <mode> <boost_root> [<source_file>] Purpose: updates preprocessed version(s) of the header(s) in "boost\mpl\aux_\preprocessed" directory Example: the following command will re-generate and update all 'apply.hpp' headers: preprocess.py all f:\cvs\boost apply.cpp
----- cut here -----
However, despite what the subject line says, what I really need is some way to do what's describe in the part of my post quoted up above. The code in preprocess.py doesn't help much. It includes: os.system( "preprocess %s %s %s %s" % ( boost_root, mode, file, file_path ) ) which, I assume, invokes the: preprocess.cmd in that directory. I'm assuming the extension, 'cmd' is some windows convention indicating an executable file since the above os.system call above didn't include the extension. Since I'm on linux, this wouldn't work, AFAICT. I did try: <---- cut here ------ python preprocess.py msvc70 /home/evansl/prog_dev/boost-cvs/ro/boost apply.cpp sh: line 1: preprocess: command not found Traceback (most recent call last): File "preprocess.py", line 78, in ? , "boost\\mpl\\aux_\\preprocessed" File "preprocess.py", line 68, in main
---- cut here ------
I've also searched the pp.py file for clues by searching for 'template'; however, that wasn't much help either. I'd appreciate any other suggestions for a linux user ;) TIA. -regards, Larry
Disclaimer: I didn't write this stuff and I've never run it. Larry Evans <cppljevans@cox-internet.com> writes:
On 06/10/2005 01:07 PM, David Abrahams wrote:
authors. What I need to do is change:
vectorX_c< T,C0 >
to:
vectorX_c< T,T(C0) >
for each X=1... [snip] In libs/mpl/preprocessed/ do
Larry Evans <cppljevans@cox-internet.com> writes: [snip] python preprocess.py And it should tell you everything you need to know.
Thanks David. This gave me: <----- cut here -----
Usage: preprocess.py <mode> <boost_root> [<source_file>]
Purpose: updates preprocessed version(s) of the header(s) in "boost\mpl\aux_\preprocessed" directory
Example: the following command will re-generate and update all 'apply.hpp' headers:
preprocess.py all f:\cvs\boost apply.cpp
----- cut here -----
However, despite what the subject line says, what I really need is some way to do what's describe in the part of my post quoted up above.
You mean you want to change some of the code that is generated by the preprocessor? You have to figure that out by finding the source file that generates it. I'm guessing boost/mpl/vector/aux_/numbered.hpp. Then you edit it. You can test your changes by compiling with -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -- MPL will then use your change directly. Then you can try the ideas below to generate new preprocessed headers.
The code in preprocess.py doesn't help much. It includes:
os.system( "preprocess %s %s %s %s" % ( boost_root, mode, file, file_path ) )
which, I assume, invokes the:
preprocess.cmd
in that directory. I'm assuming the extension, 'cmd' is some windows convention indicating an executable file since the above os.system call above didn't include the extension. Since I'm on linux, this wouldn't work, AFAICT. I did try:
<---- cut here ------
python preprocess.py msvc70 /home/evansl/prog_dev/boost-cvs/ro/boost apply.cpp sh: line 1: preprocess: command not found Traceback (most recent call last): File "preprocess.py", line 78, in ? , "boost\\mpl\\aux_\\preprocessed" File "preprocess.py", line 68, in main
---- cut here ------
I've also searched the pp.py file for clues by searching for 'template'; however, that wasn't much help either.
Why would you expect to find 'template?'
I'd appreciate any other suggestions for a linux user ;)
I would: change the script to write '#!/bin/sh\n' into the beginning of preprocess.cmd when not on Windows change the script to set the mode on "preprocess.cmd" to +x after writing it change the os.system call to say "preprocess.cmd" HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 06/10/2005 03:35 PM, David Abrahams wrote:
Disclaimer: I didn't write this stuff and I've never run it.
Fair enough. Thanks for the help though.
Larry Evans <cppljevans@cox-internet.com> writes: [snip]
I've also searched the pp.py file for clues by searching for 'template'; however, that wasn't much help either.
Why would you expect to find 'template?'
Because I was under the mistaken assumption that the python code, somehow was the only step in generating the files. Now I'm guessing that the preprocessing done by preprocess.cmd does most of the work and the python code does some minor adjustments. I'm guessing that the only reason for the python code is to save the user from having to regenerating the code with the preprocessor each time he compiles. IOW, the code in aux_/preprocessed is sort-of a cache or somewhat like a pre-compiled header.
I'd appreciate any other suggestions for a linux user ;)
I would:
change the script to write '#!/bin/sh\n' into the beginning of preprocess.cmd when not on Windows
change the script to set the mode on "preprocess.cmd" to +x after writing it
change the os.system call to say "preprocess.cmd"
I did something like that, as you can see from my other post. However, instead of naming the script file, preprocess.sh, I renamed it preprocess and invoked it with: cpp = os.path.join(".","preprocess") os.system( "%s %s %s %s %s" % ( cpp, boost_root, mode, file, file_path ) ) I'm guessing that windows will not mind if cpp is ".\preprocess" instead of just "preprocess".
Larry Evans wrote:
Why would you expect to find 'template?'
Because I was under the mistaken assumption that the python code, somehow was the only step in generating the files. Now I'm guessing that the preprocessing done by preprocess.cmd does most of the work and the python code does some minor adjustments. I'm guessing that the only reason for the python code is to save the user from having to regenerating the code with the preprocessor each time he compiles. IOW, the code in aux_/preprocessed is sort-of a cache or somewhat like a pre-compiled header.
The point of preprocessing certain headers is just to save the compiler from having to preprocess them on each compilation. The main work is done by the preprocessor itself. As I understand it, the Python script just makes the preprocessed code compact and readable. If you look at some preprocessed code you'll often see long sequences of blank lines. Also, the ouput of Boost.PP is generally not nicely formatted. Jonathan
On 06/10/2005 05:09 PM, Jonathan Turkanis wrote:
Larry Evans wrote: [snip] The point of preprocessing certain headers is just to save the compiler from having to preprocess them on each compilation. The main work is done by the preprocessor itself. More specifically, by the preprocess.py's:
os.system( "preprocess %s %s %s %s" % ( boost_root, mode, file, file_path ) ) IIUC. But then why isn't the result of this preprocessing and then clean-up by the python code placed in: boost/mpl/<basename>.hpp instead of in: boost/mpl/aux_/preprocessed/<mode>/<basename>.hpp where <basename> is some basename of the files in boost/mpl/*.hpp and <mode> is some directory in boost/mpl/aux_/preprocessed and also, apparently, one possible value of mode in: def process( file, boost_root, dst_dir, mode ): in libs/mpl/preprocessed/preprocess.py? The way it's done now, by using some preprocessing flags in: boost/mpl/<basename>.hpp to indicate whether: boost/mpl/aux_/preprocessed/<mode>/<basename>.hpp is to be included or not, makes it harder to understand what's going on.
Larry Evans wrote:
On 06/10/2005 05:09 PM, Jonathan Turkanis wrote:
Larry Evans wrote: [snip] The point of preprocessing certain headers is just to save the compiler from having to preprocess them on each compilation. The main work is done by the preprocessor itself. More specifically, by the preprocess.py's:
os.system( "preprocess %s %s %s %s" % ( boost_root, mode, file, file_path ) )
IIUC.
But then why isn't the result of this preprocessing and then clean-up by the python code placed in:
boost/mpl/<basename>.hpp
instead of in:
boost/mpl/aux_/preprocessed/<mode>/<basename>.hpp
That would overwrite the source code, which would make it impossible for users to turn off preprocessing or to use the source with the full range of supported compilers. Jonathan
On 06/10/2005 03:08 PM, Larry Evans wrote: [snip]
quoted up above. The code in preprocess.py doesn't help much. It includes:
os.system( "preprocess %s %s %s %s" % ( boost_root, mode, file, file_path ) )
which, I assume, invokes the:
preprocess.cmd
in that directory. I'm assuming the extension, 'cmd' is some windows
I changed the above to: os.system( "./preprocess.sh %s %s %s %s" % ( boost_root, mode, file, file_path ) ) and copied preprocess.cmd to preprocess.sh, edited to to become: #!/bin/bash gcc -E -C -P -I$1 "-D BOOST_USER_CONFIG=<$1/libs/mpl/preprocessed/include/$2/user.hpp>" -D BOOST_MPL_CFG_NO_OWN_PP_PRIMITIVES $3 >$4 then changed the "\" in the filename's to os.path.join and it executes without error, but I'm still looking for some hint as to how change the code to generate: vectorX_c< T,T(C0) > instead of: vectorX_c< T,C0 > TIA.
I've also searched the pp.py file for clues by searching for 'template'; however, that wasn't much help either.
I'd appreciate any other suggestions for a linux user ;)
TIA.
-regards, Larry
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Larry Evans <cppljevans@cox-internet.com> writes:
On 06/10/2005 03:08 PM, Larry Evans wrote: [snip]
quoted up above. The code in preprocess.py doesn't help much. It includes: os.system( "preprocess %s %s %s %s" % ( boost_root, mode, file, file_path ) ) which, I assume, invokes the: preprocess.cmd in that directory. I'm assuming the extension, 'cmd' is some windows
I changed the above to:
os.system( "./preprocess.sh %s %s %s %s" % ( boost_root, mode, file, file_path ) )
and copied preprocess.cmd to preprocess.sh, edited to to become:
Won't help; the script generates new .cmd files over and over. Adding a .sh extension buys nothing and impairs portability to windows.
#!/bin/bash gcc -E -C -P -I$1 "-D BOOST_USER_CONFIG=<$1/libs/mpl/preprocessed/include/$2/user.hpp>" -D BOOST_MPL_CFG_NO_OWN_PP_PRIMITIVES $3 >$4
then changed the "\" in the filename's to os.path.join and it executes without error, but I'm still looking for some hint as to how change the code to generate:
vectorX_c< T,T(C0) >
instead of:
vectorX_c< T,C0 >
As I've tried to say, you need to analyze the PP lib code used in the mpl headers; I even pointed you at a likely candidate file in my last post. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 06/10/2005 06:15 PM, David Abrahams wrote: [snip]
Won't help; the script generates new .cmd files over and over. Adding a .sh extension buys nothing and impairs portability to windows.
The date on the .cmd file is: 2004-09-02 10:41 Since I've run preprocess.py several times today, I don't think it overwrites that file. I've also changed the script, as described in: http://article.gmane.org/gmane.comp.lib.boost.devel/125881 In a way which, AFAICT, will allow it to work on both windows and linux.
[snip]
As I've tried to say, you need to analyze the PP lib code used in the mpl headers; I even pointed you at a likely candidate file in my last post.
Yes, thanks, I have looked at it and will focus my attention on that now.
On 06/10/2005 06:15 PM, David Abrahams wrote: [snip]
As I've tried to say, you need to analyze the PP lib code used in the mpl headers; I even pointed you at a likely candidate file in my last post.
Yes, thanks, I have looked at it and will focus my attention on that now. I tried modifying boost/mpl/vector/aux_/numbered_c.hpp but saw no change in boost/mpl/aux_/preprocessed/<mode>/vector_c.hpp. So, I removed
On 06/10/2005 06:34 PM, Larry Evans wrote: the -P flag from the preprocess.cmd and discovered boost/mpl/aux_/sequence_wrapper.hpp was producing the output. This was confirmed by changing sequence_wrapper.hpp and seeing a corresponding change in <mode>/vector_c.hpp.
On 06/11/2005 07:26 AM, Larry Evans wrote: [snip]
boost/mpl/aux_/sequence_wrapper.hpp was producing the output. This was confirmed by changing sequence_wrapper.hpp and seeing a corresponding change in <mode>/vector_c.hpp. I've made a small change to sequence_wrapper.hpp:
# define AUX778076_CONVERT_CN_TO(z,n,TARGET) \ TARGET(BOOST_PP_CAT(C,n)) \ /**/ # define AUX778076_SEQUENCE_N_ARGS(n) \ T BOOST_PP_COMMA_IF(n) \ BOOST_PP_ENUM(n,AUX778076_CONVERT_CN_TO,T) \ /**/ and it does what I want with the vector_c.hpp files: : vector1_c< T, C0 > changed to : vector1_c< T, T(C0) > and similar changes to vectorN_c. This allows T to be an enumeration without the compiler generating errors about long not being implicitly convertable to T. However, I don't know what effect it'll have on other files; so, I thought I'd just upload it to sandbox instead of main cvs unless some experts think it would be OK to upload to main cvs. Please let me know.
participants (3)
-
David Abrahams -
Jonathan Turkanis -
Larry Evans