extern: index
intern: preamble | setup | sample | compiling | downloads | end
main scripts: amsrcs and createdsp
2010/12/29:2010/12/04:2010/09/22:2010/09/13:2010/09/06:2010/09/04: Page updates... looks complete...
This started, circa 2005, perhaps before, as a way to update the MSVC build files (DSW/DSP) for Simgear (SG) and FlightGear (FG), so the first perl script by Curt, was called 'am2dsp.pl'. But this was a very specialized script to work only with SG and FG. But there were many other open source projects that either had no MSVC (DSW/DSP or SLN/VCPROJ) build files, so I attempted to generalize the script.
But the specialization for SG/FG was too big to allow for this, so I started on more generalized scripts, 'amsrcs.pl', and 'am2list.pl', each of which start by scanning the 'configure.ac', or 'configure.in', file looking for MACROS, and 'AC_OUTPUT', to get the 'Makefile' list created, then scan each 'Makefile.am' files based on this output list. The 'Makefile.am' is not really a 'makefile' at all, but more like a specialized 'project description file'.
But sometimes the 'Makefile.am' was missing in the downloaded source, so an attempt was made to expend this to scan the 'Makefile.in' files, which are more like the 'Makefile' used by the 'make' tool, or 'nmake' tool in windows. But this is not easy, since many times the 'Makefile.in' has lots of macros that must come from the 'configure.ac', or 'configure.in' files.
But this lead further to the 'makesrcs.pl' script which is intended to read pure makefiles, that is those used by make and nmake, and create a MSVC DSW/DSP build file set. This attempts to convert those source that do have a list of makefiles, like say 'makefile.vc', 'makefile.msvc', etc.
And more recently, 'acscan.pl', to just scan configure.ac files, and produce a content output, to try to understand all the constructs that make up a configure.ac file, and 'amscan.pl', to just scan Makefile.am project descriptions files, and follow any SUDBIRS entries to other Makefile.am files, and produces an output.
While the now not used 'am2dsp.pl' script, since SG/FG now has a WIN32 person to keep MSVC build sets up-to-date, could easily handle SG/FG, and since these were somewhat constant, and the script was initially written and maintained by the same person that maintained the configure.ac, and Makefile.am file set, the generalization has the handle the myriad of 'options', that can be put in the 'configure.ac' file, and this is just NOT easy.
Finally, sometimes I knew, or could easily manually find, the list of source files, so create the 'createdsp.pl' script, which is intended to only work from a simple list of source files. Since this is just from source, which has little or no 'project' type information, you have to instruct the script what 'type' of project it is, like a Console Application (CA), static library (SL), etc...
It should be NOTED, this is all quite a messy process, and these scripts have just grown over time, so are most certainly NOT necessarily good perl coding. In fact initially they came about to handle some very specific open sources I had downloaded, and I would just begin modifying to suit the 'new' circumstances. In other words, they are MORE just SAMPLE CODE, of what can be done, rather than any form of releasable working applications.
With the above note in mind, which in essence probably applies to ALL my perl scripts, feel free to give them a try, and I would try to answer any specific queries about them.
Of course you have to have a perl runtime installed, with the usual packages. I mainly use perl, version 5.10.0 or above, from ActiveState, but they should run with just about any recent version. These scripts do not use any particular 'special' packages, but of course you can always install any missing packages using say the Perl Package Manager GUI, ppm, or from say CPAN (C:\some-path> perl -MCPAN -e shell), or whatever your runtimes source is...
All these scripts are intended to be run in Windows only, although they would probably run in other places with some relatively minor adjustments, one of which would be the first line in each, to point to the perl interpreter in that system, which is 'ignored' in windows.
But one essential problem is that in say unix/linux is the line endings of the DSW/DSP build files. The standard file output would be a unix line ending, \n, or LF character, and while MSVC seems to handle DSW files with such a line ending, it will advise the DSP file is corrupt. Of course it is a trivial matter to then 'convert' these files to a Windows line ending, which is \r\n, CR + LF characters.
In all my systems, XP and Vista, these scripts, and their 'include' files, that is those declared with the 'require' statement, and in a folder C:\GTools\perl, so to use them WITHOUT CHANGE it would be necessary to put them in the SAME folder in your machine. And some later scripts create another directory below that, 'temp', where the sometimes MANY (temp) DSP files are written, and other things...
Alternatively, near the top of each 'main' script, there will be an entry 'C:\GTools\perl' which will need to be changed to the folder where you have placed them all. Note, if placed in double quotes ("), then that needs to be of the form "C:\\GTools\\perl" - that is the back slash (\) escaped. While in general Windows tolerates the forward slash (/) in most case, they are meant to be run in windows, so you should use the back slash (\).
So that these scripts can be run from anywhere, they push this folder into the special @INC global variable, so the perl runtime will search in this place as well.
Also, in MOST scripts, this 'perl' folder will be the output destination for the DSW/DSP files, in the form temp.proj_name.dsp, sometimes in the 'temp' folder created, but usually there is then an update batch file written to quickly copy the files to a desired target location, after review. Of course the DSP sources have all been written using a relative path address to the destination folder, so they have to be COPIED before that can be used. Even though I am now quite confident of my rename_to_old_bak() function, will do exactly that I always have the horror of overwriting some build file that I want to keep, so all script create only 'temp' files.
Further, no special effort has been made to support paths, and especially file names containing the space character, and using such file names, or paths, MAY break some of the script, and would certainly NOT function in the 'update' batch file, if there is one. Of course in Windows, and command dir /X *.*, should show the old 8.3 formatted names, which can be used instead.
Later scripts usually have a 'target' directory parameter, since again I prefer these MSVC build file live a little 'deeper' in the source folder set, like say a 'msvc' folder, sometimes even 'builds\msvc' or 'projects\msvc', etc, so that it can be easily removed later, and is out of the way of say repository updates, although here too I generally download/checkout/clone the source in one folder, which I call the 'SOURCE' folder, and copy all this source to a 'WORK' folder, to do the compile...
This gives me the possibility of doing a 'diff', to create a patch file, against the pristine source I started with. And even if I do do a later repository update of the 'SOURCE' I can review the updates, and if necessary, manually merge changes into my 'WORK' folder. I have my own tool for this, namely dc4w, but also find the open source WinMerge extremely helpful during a merge.
And of course all compiler and linker output is also then totally within this maybe 'new' folder. Naturally, if such a target directory is given, then effort is made to use a relative SOURCE= file address in the DSP file.
Most of my script have copious output, all using the self defined function sub prt($) { ... }, and not only does this function output the text to the screen, it ALSO writes it to a LOG FILE, for later full review of the output, especially if lots of 'debug' flags are put on. The NAME and location of the LOG file will be of the form C:\GTools\perl\temp.<script_name.pl>.txt and if instructed, usually through a -l, or -ll command switch, will pass this log file to the windows system, to be loaded in whatever default edit you have configured. Usually this is notepad, unless you have modified it...
Most recent scripts have a 'debug' command, like -d <num>, or even -d all, to turn on a specific debug output, or ALL of them. In this mode the script can output mega-bytes of data, all of which will flash by, but can be studied in the LOG file. Rather than using the quite difficult to handle 'debug' version of perl, I tend to use this output as my 'debug' function, to be able to 'see' what is going wrong... but this 'debug' mode adds nothing to the scripts functionality in any way.
I have adopted a simple numbering system for my scripts. The earliest will be say 'am2dsp.pl', or 'am2dsp01.pl', and this trailing number will be incremented, 02, 03, etc..., each time I do some major overhaul on the script. But as can happen, sometimes the earlier numbered versions will no longer function, due to some local 'included' library file functions (require), or other factors, so it is usually BEST to get the highest numbered version available.
As far as where to install scripts, the path of least pain would be the same as me - in
C:\GTools\perl. Then you can run all scripts without change... But if you choose
otherwise, then you must alter the statement near the top of the 'main' scripts to suit (the
line like) :-
my $perl_sdir = 'C:\GTools\perl';
But since this path, or any other path you unzip the scripts into, would NOT normally be in
your PATH
environment variable, and I am not recommended it be added to that PATH, you have to be in that
folder to
run the scripts, like :-
> cd C:\GTools\perl
> amsrcs04.pl C:\Projects\libxml2\configure.in ... etc
if you have *.pl setup as 'executable', which the perl install should have done, or -
> perl amsrcs04.pl C:\Projects\libxml2\configure.in ... etc
This is a PAIN, and to get over this (having to be in the same folder as the scripts) I use
batch files to run my perl scripts from anywhere, and these batch files are in a folder in my
PATH... examples of these batch file are now included in the latest zip. With these in a PATH
folder, then the scripts can be use from anywhere...
In my case, I put all these batch files in a folder, nostalgically called c:\MDOS, but
it could be anything, which I have ADDED to my PATH environment... through
Start -> Control Panel -> Performance and Maintenance ->
System. Then click [Advanced] tab, and you should find an [Environment
Variables] button near the bottom.
In here you can add it to your 'User' variables, but I would use the 'System variables' for
this. Click on/Select 'Path', after perhaps scrolling down, and click [Edit], and
you can edit the 'Variable value', adding say a new folder to the end, after a semi colon
(;)... Of course you must close any open CMD prompts, and re-open them, to see this change in
the PATH list...
You will note this has nothing to do with where the actual 'perl' runtime is installed, which
is usually C:\Perl, and thus c:\Perl\bin, and c:\Perl\site\bin would be in your PATH. I would
NOT suggest putting these 'user' scripts anywhere near this perl runtime stuff... but you could
use c:\Perl\site\bin...
Maybe there is a better 'best practices' on this, but I do not know what that is! I
think names like 'cgi' and 'cgi-bin' suggestions are usually for web site scripts... but in
effect, perl 'user' scripts can be 'anywhere'.
Again I would stress you note I have called them SAMPLES. They were never intended as release applications, but sometimes they do their job as expected... ;=))
And NOTE, each of the links is to a text file, that is a file with a .txt extension, to stop my server having a heart failure ;=)). So after the download, you must change the extension to .pl. Also while the link name may just show the primary file name, the link should be to the latest version with a number appended...
First the older, depreciated versions, which you can skip ...
As of Sep 2010, the latest version is 08, that is 'am2dsp08.pl'. As stated, it is mainly for SG/FG source, but MAY function with others.
C:\GTools\perl> perl am2dsp8.pl -? am2dsp8: Version 0.0.8 September, 2010. Just a little help ... Usage: am2dsp8.pl [options] [file] or [directory] Options: --help (or -h, -?) = This brief help, and exit 0 --verbose (or -v) = Sets verbose mode. (v2,v3 for MORE, -dbg for ALL) --package name - Set the DSP package name (default = FGFS) --lib (or -l) - To create static library (Default is console app.) --dir path (-d) - Establish input path for source, and the am2dsp8.cfg. --check (or -c) - Check libraries, and some known include files, and exit. --cfg path\file - Use a specific configuration file, if not with source. --load_log (-ll) - Load log file at end of processing. Purpose: The original purpose was to process the GNU autotool build files, configure.ac, and each Makefile.am indicated by the AC_OUTPUT(...) macro of SimGear and Flightgear sources, with an aim of producing an up-to-date MSVC DSW/DSP build file set. While attempts were made over the years to broaden the scope, none the less, it remains quite 'specialized' for SG and FG. There are subseqent scripts, amsrcs.pl, am2list.pl, ... etc, which work harder at being fully generalised for other sources. Notes: The --cfg path\file MUST be after the --dir path, if used. Any other option beginning with '-' will abort, with a complaint ... If a file given, assumed to be the leading/primary Makefile.am If a directory given, assumed to be the source of the initial Makefile.am If no input, the current work directory assume the source of the initial Makefile.am Help exit 0 There are NO warnings ...
Then came some intermediate tries to get this right... to not only work with SimGear/FlightGear, but on just about any source that uses the GNU auto-tools to build the project...
This was an intermediate attempt at 'generalizing' the above, but it is somewhat faulty, in that it is based solely on similar scanning as 'am2dsp.pl'. For the present, further enhancement of this script has been suspended in preference for the later 'amsrcs.pl'.
C:\GTools\perl> perl am2list02.pl -? am2list02.pl: version 0.0.2 2010-08-25 Usage: am2list02.pl [options] [directory] Options: --help -h -? = This brief help! --verbose -v[num] = Sets verbose mode. (-v2 & -v3 for MORE) --package name - Set the DSP package name (default = TEMPONLY) --lib (or -l) - To create static library (Default is console app.) --groups (or -g) - Output source into 'group' folders, as original! --dir path - Establish input path for source, and the am2dsp.cfg. --check (or -c) - Check libraries, and some known include files, and exit. --cfg path\file - Use a specific configuration file, if not with source. --msvc8 - Modify, or check, the vcproj files, if found. If no -dir <path>, or 'bare' directory on command line, then current work folder assumed. Help exit 0 Closing LOG and passing C:\GTools\perl\temp.am2list02.pl.txt to system ... May need to CLOSE notepad to exit ...
This has the purpose of just scanning a single 'configure.ac' file of your choice, and sort of reporting its content. Later versions use the include file, lib_acsan.pl to do the main scanning...
One quite helpful output is from the '-d 13' switch. This shows a LIST of 'missing'
substitution macros, in the form as following, during the running :-
[13] 29: Failed on MACRO [PLIB_DIR] = [$with_plib], [1] [with_plib], in file
[<file>]
and at the end, as a summary, like :-
Missing [with_plib], in [30:<file>]
and gives you the chance to supply a value, with '-m key value' command, like say :-
'-m with_plib <some\path>', or '-m with_plib ""', if NO path
desired.
And since this can get quite tedious to supply a long complicated command line, with MANY macros, then the is a command to read the command input from a 'response' file, namely '-r file'. So as you find these needed macros, you can add them into that response file, remembering to still use "" if you want to define it as no path.
C:\GTools\perl> perl acscan03.pl -? acscan03.pl: version 0.0.1 2010-08-31 Usage: acscan03.pl [options] in-file Options: --help (-h or -?) = This help, and exit 0. --dbg <num> (-d) = Set DEBUG flag of this value. Number in range 1 to 19 --load-log (-l) = Load log file at end. (def=Off) --mac item val (-m) = Store a MACRO, item=value, for substitution. (use '-d 13' to list missing). Purpose: Scan the input file as a configure.ac file, and display its contents. NOTES: The debug switch is strictly for that. It adds no functionality, just a noisier output, and has the text settings of 'all', 'none', or 'help', to show the list in more detail.
Has the purpose of scanning a given Makefile.am file, but if a SUBDIRS entry is found, then will trace into each, scanning any Makefile.am file present, thus following the make file chain as it were....
The BIG problem with directly scanning a GNU autotool Makefile.am project description file like
this is that usually MANY macro substitutions fail, macros which are usually supplied through
the configure.ac file scan. But to assist in this, there is a command switch to add a macro,
like say -
'-m with_plib <some\path>', or '-m with_plib ""', if NO path
desired.
If debug '-d 13' or '-d 14' are ON, then not only is this 'missing' macro list output, but a 'missing.txt' file is also written containing the list, so after reviewing this file, since initially ALL are defined as a 'blank' (""), then you can load this as a response file using '-r missing.txt', and thus supply all the macro substitutions desired.
That response file also contains some other INTERNALLY initialized 'common' items, so they can be reviewed and their value changed as desired. That is, if items are initialized by user input, then the internal adding is skipped... To be sure, these MACRO are an important part of running amscan.pl, but are not essential! It will do its jobs of showing the SOURCES of LIBRARIES and PROGRAMS found in the Makefile.am scanning.
C:\GTools\perl> perl amscan02.pl -? main::process_one_am_file() called too early to check prototype at amscan02.pl line 553. Prototype mismatch: sub main::am_macro_split ($) vs ($$) at C:\GTools\perl/lib_amscan.pl line 188. Subroutine am_macro_split redefined at C:\GTools\perl/lib_amscan.pl line 133. Variable "$dbg_s19" is not imported at (eval 41) line 2. amscan02.pl: version 0.0.2 2010-09-05 Usage: amscan02.pl [options] in-file Options: --help (-h or -?) = This help, and exit 0. Variable "$dbg_s19" is not imported at (eval 78) line 2. --dbg <num> (-d) = Set DEBUG flag of this value. Number in range 1 to 18 --load-log (-l) = Load LOG file at end. --mac item val (-m) = Store a MACRO, item=value, for substitution. (use '-d 14' to list missing). --quick (-q) = Be quick. This turn OFF any directory scanning for sources. --subdir (-s) = Process SUBDIR entries, and ALL Makefile.am files found. --resp <file> (-r) = Commands from a reponse/input file. --targ <dir> (-t) = Establish a target directory for the DSW/DSP files. Purpose: Read the file given as a GNU Makefile.am autotools project description file, and show its contents. If the --subdir (-s) command is given, and it contains any SUBDIRS = macro, then it check each sub-directory for a Makefile.am file, and if found, process it also. NOTES: The debug switch is strictly for that. It adds no functionality, just a noisier output, and has the text settings of 'all', 'none', or 'help', to show the list in more detail. While this script does NOT output DSW/DSP files, if given a target directory, the source file lists for each project source listed will be adjusted as if the DSP file was in this target directory. The default will be the same directory as the primary Makefile.am file. This script does NOT function with a Makefile.in, which is more like a 'standard' makefile that would be used by the 'make', or 'nmake' tools in windows. Variable "$dbg_s19" is not imported at (eval 115) line 2. Help exit(0) time:Mon Sep 13 12:02:23 2010
This is a different beast entirely. It still outputs a DSW/DSP build file set, but uses a 'standard' makefile, that used by 'make', and 'nmake' in windows. This is NOT very successful, since there are just so many ways this file can be constructed, and so many options, but it does its best ;=))
C:\GTools\perl> perl makesrcs02.pl -? makesrcs02.pl: version 0.0.2 2010-08-23 Usage: makesrcs02.pl [options] makefile Options: --help ( -h -?) = This help, and exit 0 --dbg <num> (-d) = Set DEBUG flag of this value. Number in range 1 to 14 --in <file> (-i) = Commands from an input file. --load-log (-l) = Load log at end. --mac itm val (-m) = Store a MACRO, item=value. --targ <dir> (-t) = Target directory for DSP file. If none given then that of the input file. Purpose: Attempts to read the 'makefile' input file, and output a DSP file to [C:\GTools\perl\temp2010.dsp] Notes: The input file is a set of line delimited commands. Lines beginning with '#' are skipped. The debug switch is strictly for that. It add no functionality, just a noisier output, and has the text setting of 'all', 'none', or 'help', to show the list in more detail. Warning: Paths, or more importantly, File name with spaces may NOT be handled correctly. Remember the command 'dir /X *' will display the 8.3 DOS format names to use instead. Help exit(0)
In essence, this is a combinations of acscan.pl, and the amscan.pl, but with the added bonus that a DSW/DSP build file set is also written. That is, it first scans the 'configure.ac', or 'configure.in' file to (a) set up the set of macro substitutions where needed, and (b) finds the set of AC_OUTPUT make-files, then (c) scans each Makefile.am file indicated, and (d) outputting a DSP for any LIBRARIES or PROGRAMS, plus SOURCES found in each Makefile.am.
C:\GTools\perl> perl amsrcs04.pl -? amsrcs04.pl: version 0.4.24 2010-12-30 Usage: amsrcs04.pl [options] in-file --help (-h or -?) = This help, and exit 0. Purpose: Scan the input file as a configure.ac file, then scan the Makefile.am entries indicated by the AC_OUTPUT macro, and output MSVC DSW/DSP build files for the contents found. NOTES: Auto output does the following, and more: For libraries: D:'/out:"lib\barD.lib"'; R: '/out:"lib\barD.lib"'. For programs: D:'/out:"bin\fooD.exe"'; R:'/out:"bin\foo.exe"' Use '-a help' for fuller list of this 'auto' feature BIT effects. Do NOT add the /D or /I to the macro defined or included. This will be added internally, and note the upper case for -D, -I and -L. Setting a macro is 3 entries, like '-m item value', thus if set a blank is required, use '-m item ""'. Macros substitutions found missing are written to the file [C:\GTools\perl\temp\missed_mscro_list.txt] for review, and then use as a '-r <file>' response input file. The debug switch is strictly for that. It adds no functionality, just a noisier output, and thus allow a DEBUG view of what the script 'saw', and 'did' to potentially 'fix' the script. Unless there are two commands using the same letter, normally case, and after the first letter are ignored. The LIB <set> consists of <name:path:(D|R|B)[:project]>. The 'name' can be a single name, or a semicolon separated list of library names. The 'path' can be blank, absolute, or relative to the 'target' directory of the program DSP. D=Debug, R=Release, B=Both. If no optional project name is given, then the library (or libs) are added to all, except Static Libraries (SL). RESTRICTION - libraries should be added WITHOUT a PATH. The 'path' should only be given as 2nd value. Options: --auto on|off|v (-a) = Automate certain preferred outputs. '-a help' for MORE. (def=-1) --cond item (-c) = Define a conditional item. Can add [:1|0]. Default is 1 (TRUE). --dbg <num> (-d) = Set DEBUG flag of this value. For AC lib_acscan, numbers in range 101 to 120 For AM lib_amscan, numbers in range 201 to 224 Text setting are 'all', 'none', 'extra', and 'help'. --DEF mac[:nam] (-D) = Add a global defined macro, OR to a specific ':project', if given. --INC <path> (-I) = Add an include macro, like '/I "path"', to the DSP compile. --join nam list (-j) = Join the semicolon separated 'list', to project of type, like 'nam:type'. Can be 'a:t a;b;c', or 'd:t a;b;c'. Type is per -T below, and can have semicolon separated sources following another colon. --LIB <set> (-L) = Add a global dependant libraries, to programs being built, OR to just to a specific project, if given. See NOTES: --load-log (-l) = Load log file at end. (def=Off) --mac item val (-m) = Store a MACRO, item=value, for substitution. (use '-d 13' to list missing). --name <name> (-n) = Overrride any name in the AC_INIT/AM_INIT_AUTOMAKE. --out <dir> (-o) = Give existing DSP output directory, relative or absolute. Will NOT be created. (def=C:\GTools\perl\temp). --resp <file> (-r) = Commands from a reponse/input file. --supp_in (-s) = Support Makefile.in, if NO Makefile.am found. (def=0) --TYPE nm:type (-T) = Set other than default types for project name : types CA|WA|SL|DLL, and the type can be followed with additional 'sources'. name:type:src1;src2;... --targ <dir> (-t) = Establish a target directory for the DSW/DSP files. --verbosity (-v) = Bump verbosity of this module. Default [0] to 9 (-vvvvvvvvv) --wr_dbg <num> (-w) = Add debug during the DSP write output. Bit values. -1 for all. --xclude <set> (-x) = Exclude a 'project', or sources, from a project. A 'set' consists of a project names, optionally followed, after a colon, by a semi-colon separated list of sources. eg proj:src1;src2'... No missing conditionals listed. [13] There are NO missing substitutions. No warnings issued. Current CMD: [-?] Help exit(0) time:Thu Dec 30 14:52:02 2010 (0)
The idea of this script is to start a simple input response file, -r proj.inp, and as changes are found, and the response file adjusted, the script REPEATED. And REPEATED, until the project can be built, even if in the process some sub-projects were excluded... Thus repeat, Repeat, REPEAT is the mantra of this script ;=))
However, when a project source does NOT include the automake files, like configure.ac (or configure.in), and/or is missing the Makefile.am files (or at least the Makefile.in) files, then 'amsrcs' fails. As an alternative, this script, 'createdsp' directly creates a DSP file for the project name, type, sources.. entered...
This is a script where you describe a project, by giving a source list, and a type of project, and it will create a DSP build file from this information...
createdsp03.pl: version 0.3.5 2011-10-16. (see amsrcs04.pl for fuller implementation.) Usage: createdsp03.pl [options] source [source...] Options: --help (-h -?) = This help, and exit(0) -@<inpfile> = Read input parameters from a file. -name <name> (-n) = Set the project name. -targ <dir> = Set a target directory for the DSP file. -type <CA> = Set project type. Only 'CA', 'SL', 'DLL', 'WA' -def <FGFS> = Add a define macro, /D "FGFS" to the compile. -inc <path> = Add an include macro, /I "path" to the compile. -int(d|r) <dir> = Set output and intermediate directory, for objects, etc. -lib <lib> = Add a library to the compile, both Debug and Release. -libd <lib> = Add a library to the compile, for Debug only. -libr <lib> = Add a library to the compile, for Release only. -libp <path> = Add a library path, ie /libpath:"path" to BOTH Debug and Release. -outd <fd.exe> = Add an /out:"fd.exe" to Debug. -outr <f.exe> = Add an /out:"f.exe" to Release. -outdefault = Set output per project name, and type, adding 'd' for debug -outdsw = Set to write a DSW file to load this DSP file. -rt <D|T> = Set RUNTIME D=/MD & /MDd T=/MT & /MTd (default). -src <fil[;fil> = Semicolon delimited source file input, instead of 'bare' names. -srcdir <dir> = Common source directory to be applied to each subsequent source. -v[num] = Bump or set verbosity. Default=0 -l = Load log file at end. PURPOSE: Generate a DSP project file to compile this/these given sources, which can be 'C/C++' sources, headers and/or resource files. NOTES: 1: The -@<inpfile> is a text file with line delimited parameters. Lines beginning with a '#' are treated as comments, and skipped, as are blank lines. 2: In general the sources given are assumed to one level up. That is given the command - > createdsp03.pl -type=CA foo.c foo.h the destination of the DSP file will be assumed to be one level down, say in .\msvc\foo.dsp and the sources will be listed as 'SOURCE=..\foo.c'. This is a feature by design. 3: Dependant library paths given are assumed for BOTH Debug and Release, the idea being that such dependant libraries will be of the form 'bar.lib', and 'bard.lib' both residing in the SAME -libp<path>. This may means you need to adjust to library names, and location. Help exit(0)
Older version 02 - 22/09/2010 createdsp02.pl
All of the above, at least the latest versions, are included in the most recent downloadable ZIP file below.
Each of the above have 'include' files. That is files included through the use of 'require', as
opposed to 'use' declaration, so it is necessary to also download some, or all, of the
following :-
fgutils02.pl,
lib_acscan.pl,
logfile.pl,
relative.pl,
chkmain.pl, utils.pl,
fgdsphdrs03.pl,
scanvc.pl
lib_amscan.pl,
lib_utils.pl, and maybe more.... ALL of these are
also included in the downloadable ZIP file below.
And since most of these scripts output MANY files of the form 'temp<something>, I have a batch file, 'CLOBNOW.BAT', to do the cleanup. It also cleans up many of the 'temporary' files created by MSVC. Since it uses 'del temp*.*, one has to be careful it does NOT also delete files like template.*, which may be needed.
And since certain scripts output MSVC6 DSW/DSP files, which are converted by later MSVC versions to SLN/VCPROJ build files, another cleanup batch file I use is 'DELSLN.BAT' to blow away all the MSVC later converted files, so one can start again with just the DSW/DSP files... These are also included in the latest version of the downloadable ZIP file below.
While these scripts can HELP in producing the MSVC build files, DSW/DSP, it is a whole other thing to now compile unix/linux sources in Windows. My particular modus operandi is to repeatedly force the MSVC IDE to compile just one source, until it is clean - right click on source file, and select 'Compile...' - otherwise you can be overwhelmed by the sometimes enormous list of apparent problems ;=))
To change the source file or header itself should be avoided, if possible. But if it is necessary, then of the most common macros is one of the following blocks -
#ifdef _MSC_VER /* code for windows only */ #else /* !_MSC_VER */ /* code for unix/linux only */ #endif /* _MSC_VER y/n */ #ifdef _MSC_VER /* add code for windows only */ #endif /* _MSC_VER */ #ifndef _MSC_VER /* chop some unix code */ #endif /* !_MSC_VER */
In this fast approaching age of 64-bits, the very commonly seen macro of #ifdef WIN32, or the more or less equivalent '_WIN32' is not recommended, but is USED quite a lot. And remember if the 'fix' is in a library header, then that 'fix' must also work in the final application that ends up including that header when using the library.
And be prepared for problems to repeat. It is for sure true that once a programmer adopts a style, he/she may use it repeatedly. In some case I have written a short say perl script to perform the change ;=))
To address some of the common problems...
config.h - One of the most common 'missing' headers is 'config.h'! This is usually because this file is in fact GENERATED by the GNU autotool processing, and is thus NOT usually included in the distributed source. But it is a simple matter to handcraft one, which I usually place in the same folder as the DSW/DSP files, and make sure a 'local' search is added to the 'additional include directories' of MSVC, namely '.', or /I "." as seen in a DSP file.
Often these autotool generated 'config.h' files will have MANY entries of the form
HAVE_<header>_H, like say HAVE_ALLOCA_H. But unfortunately the accompanying
source may not be coded to 'obey' all these directives, and say have an unconditional :-
#include <alloca.h>
which does NOT exist in windows. This causes a compile error. Sometimes all that is
required is to encase such an include in an #ifdef macro, like -
#ifdef HAVE_ALLOCA_H
#include <alloca.h>
#endif
Some sources have a config.h.in file, which can often be used as the basis of a MSVC hand crafted 'config.h', but recognize that often not all defines of the form HAVE_<header>_H are used in the source, and sometimes they need to be added for native 'windows'. Also some source, especially those which have previously had some work done on a native windows port, may have say a config.h.vc, config.h.msvc, etc, which can again form the basis of the final 'config.h'
version.h - Usually, if required, is another GENERATED file, so for windows it is often necessary to create one, and perhaps use an educated guess for the actual 'VERSION'. Sometimes a string is required, sometimes an integer... depends on the source... Sometimes some 'clues' can be had from a version.h.in file, if present.
unistd.h - The inclusion of this header is ubiquitous in unix/linux source, and only sometimes it is within an #ifdef HAVE_UNISTD_H macro. Here there are two choices - (a) add the macro around the inclusion, or (b) create such a file. I flip both ways on this ;=)) It is certainly NOT recommended, even if you have access to a unix/linux machine, that you copy it from there, because you will find that it then includes a number of other files, some in sub-directories... sort of like chasing your tail... some things used found in this file are -
/* Standard file descriptors. */ #define STDIN_FILENO 0 /* Standard input. */ #define STDOUT_FILENO 1 /* Standard output. */ #define STDERR_FILENO 2 /* Standard error output. */ /* Values for the second argument to access. These may be OR'd together. */ #define R_OK 4 /* Test for read permission. */ #define W_OK 2 /* Test for write permission. */ #define X_OK 1 /* Test for execute permission. */ #define F_OK 0 /* Test for existence. */
inttypes.h - Unix uses lots of 'typedef' items which are not available in Windows. The set I seem to need all the time includes :-
typedef char int8_t; typedef unsigned char uint8_t; typedef short int16_t; typedef unsigned short uint16_t; typedef int int32_t; typedef unsigned int uint32_t; typedef __int64 int64_t; typedef unsigned __int64 uint64_t;
stdint.h - SIMILAR to the above, unix can use lots of 'typedef' item not available in Windows. The most common set includes :-
// hand crafted stdint.h for MSVC - typical typedefs #ifndef _stdint_h_ #define _stdint_h_ /* signed. */ typedef signed char int8_t; typedef short int int16_t; typedef int int32_t; typedef long long int int64_t; /* Unsigned. */ typedef unsigned char uint8_t; typedef unsigned short int uint16_t; typedef unsigned int uint32_t; typedef unsigned long long int uint64_t; #endif //#ifndef _stdint_h_ // eof - stdint.h
sys/time.h - This can usually be replaced with the windows 'time.h', but it is sometimes necessary to also include 'winsock.h', or 'windows.h', if the structure struct timeval is used.
sys/socket.h - This can usually be replaced with Winsock.h, and thus later link to the windows WSock32.lib, or the later version, Winsock2.h, and link to WS2_32.lib. Note that these two 'windows socket' files usually HAVE to be included before 'Windows.h', and in fact including them automatically includes 'Windows.h', but sometimes the order is IMPORTANT. There are whole bunch like this, like say arpa/inet.h, but normally most can be replaced with one of the 'windows socket' files.
And there are probably many others...
While MANY functions are available in the Windows runtime libraries, there are of course some that are NOT. Usually scouting around the internet, it is sometime possible to find a very portable port, which you can add to the source, or create say a win32_glue.lib static glue library to link your application to. Here, 'createdps.pl' can come in handy, then you just add you new DSP to the current DSW, and add a dependence to this library.
Some of the most common are getoptions(), opendirectory(), gettimeofday()... but this list is hardly complete.
When compiling nearly all open source, it is normal to get 10's, 100's, even 1000's of compiler warnings... MOST can be ignored...
One of the most common is C4996. Lots of these can be suppressed by defining
_CRT_SECURE_NO_DEPRECATE either in the preprocessor settings of the MSVC IDE, or in the
'config.h', if there is one, and it is the FIRST included header. But to suppress them
_ALL_ it is often necessary to use :-
#pragma warning ( disable : 4996 )
at the head of the source file, before ANY headers are included. This is good, since other
warning 'numbers' can be easily added...
Other common warnings include -
warning C4013: 'snprintf' undefined; assuming extern returning int
(*)
warning C4018: '<' : signed/unsigned mismatch
warning C4133: '=' : incompatible types - from 'char *' to 'jack_sample_t *'
warning C4244: '=' : conversion from 'jack_t' to 'jack_id_t', possible loss of data
(*) In say a static library creation, this 'assuming' only bytes when you come to LINK with the library, and the linker eventually reports an 'unresolved external' ;=((
Sometimes the unix/linux coder has THOUGHT about other ports, like the following indication -
#ifndef JACK_WEAK_EXPORT #ifdef __GNUC__ /* JACK_WEAK_EXPORT needs to be a macro which...etc */ #define JACK_WEAK_EXPORT __attribute__((weak)) #else /* Add other things here for non-gcc platforms */ #endif #endif
and all that is required is to add the appropriate code. In this particular case of
__attribute__ there is no Windows equivalent, so it would be just defined as a 'blank', like -
#define JACK_WEAK_EXPORT
This is a VERY debatable question. There is no doubt unix/linux is moving strongly towards using mostly what it calls 'shared libraries', a dynamically linked at runtime library! And thus the developers in unix/linux tend to think the same is best for windows, so when a 'port' is done, the most common port of a shared library will be a DLL.
While the *nix OSes have their share of problems using these shared libraries - they MUST be installed in places where the 'dynamic' loader can find them - the situation is a considerable problem in windows. The 'normal' locations for installing DLL's is C:\Windows\system32, or its equivalent, which requires extra privileges in recent version of windows, to add files, and is NOT in any way recommended for such 3rd party DLL's.
It IS sufficient to 'install' DLL's in ANY folder in the PATH environment variable, or in the SAME folder as the executable requiring the DLL, but this still seems quite messy, and a hassle for some users. And in windows, a DLL actually has two components to worry about. The DLL, which is dynamically loaded at runtime, and a LIB which is used in the LINK at compile time.
So, by deliberate DEFAULT these scripts will always strive to create a 'static' library instead. One a program has been linked with such a 'static' library, that is the end of thing. It does not matter where the library actually resides.
amsrcs scripts: (evolution of am2dsp): As well as providing the direct lists above to each source, the following ZIP file contains all the perl scripts mentioned on this page.
As always, sadly, take care downloading and running scripts from the web ;=((
At least check the MD5 digest after downloading...
| date | link | size | MD5 |
|---|---|---|---|
| 2011/11/04 | am2dsp06.zip | 386,053 | 929191b48864a9d9b94721d6742f6df3 |
Windows Only: Since these scripts are for use in Windows, and sort of 'emulate' some of the functionality of unix/linux auto-tools, these scripts will probably NOT run in unix/linux without considerable modification.
Retained for historic type reasons only. They were flawed, and thus evolved into the later version given above. These can be skipped...
| date | link | size | MD5 |
|---|---|---|---|
| 2010-12-30 | am2dsp05.zip | 375,052 | 6a55c0fc9351a497cc26f34e1209923b |
| 2010-12-04 | am2dsp04.zip | 374,256 | ba75728b6d910d11b091eb7d756af246 |
| 2010-09-13 | am2dsp03.zip | 253,023 | 0c1b97b33c18ee3f92fd11bb0d0d4217 |
| 2010-09-06 | am2dsp02.zip | 183,510 | e01a1d33083b987b4f5bf9ffe724928a |
| 2010-09-04 | am2dsp01.zip | 177,521 | 9a3100bdbfc1403a570b9ae4f238f6bc |
The following scripts can be viewed in source form [ amsrcs04.txt lib_acscan.txt lib_amscan.txt lib_confscan.txt lib_dsphdrs.txt lib_params.txt lib_srcscan.txt lib_utils.txt lib_vcscan.txt createdsp03.txt ]
This 1,297,406 byte temp-am2dsp25.zip also contains some same 'input' files, for a number of different projects used in the script testing and debugging... (604d6b4aaf842aad45cd100abd9e42f4) ... see the different buildme batch files, together with samples of the batch files I use... to repeat building...
This 1,296,610 byte temp-am2dsp24.zip includes sample input response files, and buildme batch files for various projects using in the testing and development. (61f0a627348fcb4c6c4012415f2eb9f2)
And that's it for now...
EOP - am2dsp.htm