setting FileVersion from environment variable (expansion during compile time)

[francoiste]

to set the FileVersion of the compiled script we can either use:

#AutoIt3Wrapper_Res_Fileversion=1.7.100.201

or

#pragma compile(FileVersion, 1.7.0.0, 1.7.100.201)

but i need to set the version from an environment variable that is expanded during "compile time",something like this:

;pseudo code
#AutoIt3Wrapper_Res_Fileversion=#ExpandEnvironment("MyBuildNumer")

any thoughts?

similar to above i'd also need such an expansion during compile time to define a constant string:

;pseudo code
Global Const $g_sBuildInfo = "Compiled on: " & #ExpandEnvironment("COMPUTERNAME")

Edited May 14, 2014 by francoiste

[Jos]

 

any thoughts?

 

 

Write you own wrapper that to set the #PRAGMA OR #AutoIt3Wrapper_res-xxx= lines  info before the script is compiled.

Several options are available like #AutoIt3Wrapper_Run-Before= and shell a script that updates the source for you.

Jos

[francoiste]

thanks a lot, Jos.

that's a very pragmatic solution.

i'll give it a try.

still, it would be great to have official support for such types of "dynamic resolution during compile time"

either from *.txt, *.ini, environment variable.

this also avoids actually "updating" the source file (i.e. through search-and-replace).

the line simply remains un-touched - as a compiler directive.

Edited May 13, 2014 by francoiste

[Jos]

I somehow doubt that many would use a Environment variable to set a fileversion, but understand you would like to have some pre-processor capabilities to update your script.

This is currently not available nor the intent of Autoit3Wrapper.

One remark around the above idea: When you run a wrapper during the Run_Before stage which updates the source, you need ensure you create a save copy of the original before updating it, which you put back at the Run_After stage. (Hope I made myself clear )

Jos

[francoiste]

i'm still trying to avoid "updating" the source file during compilation.

so i tried to dynamically generate an include file that contains the "wrapper" directive.

but at first it didn't work:

#include "_tmp_MyBuildNumber.au3" ;this contains the wrapper line for the Res_FileVersion

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Compression=4
#AutoIt3Wrapper_UseUpx=Y
#AutoIt3Wrapper_Res_Comment=For internal use only
#AutoIt3Wrapper_Res_Description=My Super Tool
#AutoIt3Wrapper_Res_LegalCopyright=My Company 2014
#AutoIt3Wrapper_Res_requestedExecutionLevel=highestAvailable
#AutoIt3Wrapper_Res_Field=ProductName|My Tool
#AutoIt3Wrapper_Res_Field=AutoIt Version|%AutoItVer%
#AutoIt3Wrapper_Res_Field=CompanyName|My Company
#AutoIt3Wrapper_Res_Field=Product Name|My Tool
#AutoIt3Wrapper_Run_Before=echo #AutoIt3Wrapper_Res_Fileversion=%MyBuildNumber% > "_tmp_MyBuildNumber.au3"
#AutoIt3Wrapper_Run_Tidy=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

note the first "#include" and the "#AutoIt3Wrapper_Run_Before".

according to the results of different approaches there seems to be a conflict between the "pragma" resources and the "wrapper" resources.

after removing all "#AutoIt3Wrapper_Res_*" and replacing them with pragmas it's working fine.

this time the include file contains a "pragma" directive:

#include "_tmp_MyBuildNumber.au3" ;this contains the pragma for the FileVersion

#pragma compile(FileDescription, 'My Super Tool')
#pragma compile(ProductName, 'My Tool')
#pragma compile(LegalCopyright, 'My Company 2014')
#pragma compile(CompanyName, 'My Company')
#pragma compile(Comments, 'For internal use only')

#pragma compile(ExecLevel, highestAvailable)
#pragma compile(Icon, MyTool.ico)

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Compression=4
#AutoIt3Wrapper_UseUpx=Y
#AutoIt3Wrapper_Run_Before=echo #pragma compile(FileVersion, %MyBuildNumber%, %MyBuildNumber%) > "_tmp_MyBuildNumber.au3"
#AutoIt3Wrapper_Run_Tidy=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

Edited May 14, 2014 by francoiste

[guinness]

I somehow doubt that many would use a Environment variable to set a fileversion

I actually do. It's just a habit I have had for a couple of years now. Maybe should start using some sort of function or something similar.

[Jos]

I actually do. It's just a habit I have had for a couple of years now. Maybe should start using some sort of function or something similar.

How does this work then when you work on several programs?

Do you create an environment variable for each and wondering why you want to do this?

For me it works fine when the version is stored in the script itself and it automaticcally increases with each commit to the SVN I use... very low maintenance in that way.

Jos

[guinness]

It's because I have translation files that I ask translators to use %PROGVERSION% when the message displays the version number. It's easier to use _WinAPI_ExpandEnvironmentStrings() than replacing, as I have multiple %__% variables.

 

This works.

#include <MsgBoxConstants.au3>
#include <WinAPI.au3>

EnvSet("PROGVERSION", FileGetVersion(@AutoItExe)) ; Set at the start of the script. Normally I use @ScriptFullPath.

MsgBox($MB_SYSTEMMODAL, "", _WinAPI_ExpandEnvironmentStrings("This is some language string with the version number of %PROGVERSION%."))

[francoiste]

How does this work then when you work on several programs?

Do you create an environment variable for each and wondering why you want to do this?

For me it works fine when the version is stored in the script itself and it automaticcally increases with each commit to the SVN I use

 

i'm using an automated build system on a central server.

i just submit my code changes to the source code repository. that's it.

the server compiles a "product" that consists of multiple components: unmanaged binaries, managed binaries, autoit compiled script, etc.

the build number accross those individual portions must be identical. the build number is maintained (and incremented) by the server.

the automated build system is clever enough to update version related files that are later "included" by c++ and csharp projects.

(this is done on the local, temporary copies, only. the updated files are not uploaded to the source code repository.)

for build tools that are not officially supported by this ecosystem it also populates various environment variables - to be consumed by custom workarounds.

this is the context of my initial question (how to achieve it for AutoIt compiled scripts).

maintaining and incrementing the build number inside the source file itself does not fit into above concept.

instead, there is a requirement to have a "global" build number that is "included" by the various components using different technologies.

for example through compile directives / pragmas that allow expansion during compile time.

regarding your question on "several programs":

in the build system each product get's compiled in its own "context":

when compiling "ProductA" the value of "%MyBuildNumber%" has a different value than when compiling "ProductB".

this is quite handy as i can always use this exact same environment variable "MyBuildNumber" accross products.

no need to come up with different variables for different products.

PS:

meanwhile i have found a workaround and updated one of my previous posts.

Edited May 14, 2014 by francoiste

[Jos]

It's because I have translation files that I ask translators to use %PROGVERSION% when the message displays the version number. It's easier to use _WinAPI_ExpandEnvironmentStrings() than replacing, as I have multiple %__% variables.

 

This works.

_WinAPI_ExpandEnvironmentStrings("This is some language string with the version number of %PROGVERSION%.")

Will add this to the Func Convert_Variables() for the next release as its pretty simple and useful in general when people want to use EnvVars in any of the text fields.

Thanks for the idea

Jos

[francoiste]

update:

earlier i said i had found a suitable workaround by using #AutoIt3Wrapper_Run_Before to dynamically gereate the required #include file.

this worked fine when compiling from the scite.exe editor (GUI).

however, in the context of the automated build system i hit another problem.

it seems the "AutoIt3Wrapper.exe" does not execute the "Run_Before" when being invoked to compile the script from the command line:

AutoIt3Wrapper.exe" /in "%MySourceRoot%\MyTool.au3"

in turn it will not generate (or rather update) the required include file.

so by now i have discarded the approach with "Run_Before" of the wrapper.

instead, the build system is now generating the include file itself - right before doing the compilation:

REM pseudo batch
echo #pragma compile(FileVersion, %MyBuildNumber%, %MyBuildNumber%) > "%MySourceRoot%\_tmp_MyBuildNumber.au3"
AutoIt3Wrapper.exe" /in "%MySourceRoot%\MyTool.au3"

and the source of "MyTool.au3" looks like:

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Compression=4
#AutoIt3Wrapper_UseUpx=Y
#AutoIt3Wrapper_Run_Tidy=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

#include "_tmp_MyBuildNumber.au3" ;this contains the pragma for the FileVersion - generated by the build system

#pragma compile(FileDescription, 'My Super Tool')
#pragma compile(ProductName, 'My Tool')
#pragma compile(LegalCopyright, 'My Company 2014')
#pragma compile(CompanyName, 'My Company')
#pragma compile(Comments, 'For internal use only')
#pragma compile(ExecLevel, highestAvailable)
#pragma compile(Icon, MyTool.ico)

i need to admit this #pragma feature in AutoIt was new to me.

still, the initial request for some "compiler directives" to do expansion / resolution during "compile time" remains valid, i think.

Edited May 16, 2014 by francoiste

[guinness]

No problem.

[Mobius]

AutoCamo has always allowed environment variables in its build parameters, I could have sworn I nicked the idea from AutoItWrapper, I guess I didn't then.

[Jos]

Uploaded AutoIt3Wrapper Beta v 2.2.0.2 which now also does the Environment expansion for the #AutoIt3Wrapper Directives.

Format is %EnvironmentVariableName% like the internal variables. Internal will take priority in case they are the same.

Jos

[francoiste]

Uploaded AutoIt3Wrapper Beta v 2.2.0.2 which now also does the Environment expansion for the #AutoIt3Wrapper Directives.

Format is %EnvironmentVariableName% like the internal variables. Internal will take priority in case they are the same.

 

big thanks, jos!!

this will make things a lot easier when using the wrapper.

still, there's no solution to the secondary question how to do compile time expansion to define variables:

;pseudo code
Global Const $g_sBuildInfo = "Compiled on: " & #ExpandEnvironment("COMPUTERNAME")

for this task i'm currently continuing with the approach to have some include files generated "externally", before invoking the compilation.

Edited May 17, 2014 by francoiste

[Jos]

 

still, there's no solution to the secondary question how to do compile time expansion to define variables:

;pseudo code
Global Const $g_sBuildInfo = "Compiled on: " & #ExpandEnvironment("COMPUTERNAME")

This requires a total different approach more of less like au3stripper does.

You need to create a new file with the expanded/modified source which is then used as input for compilation.

Why not put that in a res_field which you can use later for display purposes, like the versionnumber?

Jos

Edited May 17, 2014 by Jos

[Jos]

big thanks, jos!!

this will make things a lot easier when using the wrapper.

still, there's no solution to the secondary question how to do compile time expansion to define variables:

;pseudo code
Global Const $g_sBuildInfo = "Compiled on: " & #ExpandEnvironment("COMPUTERNAME")

for this task i'm currently continuing with the approach to have some include files generated "externally", before invoking the compilation.

Sorry to report I had to back out this change as there is a major regression when using the GUI inside of AutoIt3Wrapper which would cause all %Variables% to be updated and displayed in the GUI, hence causing to loose the original defined %Variable%.

This is a design issue that is not easy to resolve so had to revert the changes and re-think if this can be supported together with the GUI implementation.

Jos