Relative Paths

[asantizo]

How to create an installer using relative paths for the original files? We use VSS and each developer might have a different path. We don't want to rebuild the installer every time a developer wants to create one.

thanks

[Brett]

You can't use relatve paths. However, what you can do is use a design time constant (Publish > Settings > Constants) in the path:

#LOCAL_FOLDER# = C:\Brett's Test Folder

File sources:

#LOCAL_FOLDER#
#LOCAL_FOLDER#\Data
#LOCAL_FOLDER#\Docs
#LOCAL_FOLDER#\Images
etc...

Then when you want to change the local source location, just change the DT constant value.

[Pascal v Vuuren]

Hi Brett,

I ran into a similar situation and that solution worked well for me. However, is it possible to base this off a system variable? (E.g. set from a cmd prompt) This way other developers / building system does not need to be manually configured every time.

Regards,

Pascal

[jassing]

I ran into a similar situation and that solution worked well for me. However, is it possible to base this off a system variable? (E.g. set from a cmd prompt) This way other developers / building system does not need to be manually configured every time.

While not ideal; I put the sf7 files in the "root" of the project I'm working on -- then I use "relative" paths based on #PROJECTFILEDIR#

[Pascal v Vuuren]

While not ideal; I put the sf7 files in the "root" of the project I'm working on -- then I use "relative" paths based on #PROJECTFILEDIR#

Thank you, that is an interesting solution to the problem. I'll need to see if anybody in the team has any objections to relocating the Installation Scripts to the project root, but that sounds like it would work.

[jassing]

Thank you, that is an interesting solution to the problem. I'll need to see if anybody in the team has any objections to relocating the Installation Scripts to the project root, but that sounds like it would work.

For one client, they use vault (like source safe) to store files; and everyone has a different directory structure on their local machines. Since switching to #PRJOJECTFILEDIR# no one has complained about missing files.

I use #SUFDIR# for all includes.
the #projectfiledir# works 'everywhere' (files, output, incldues).

Good luck.
-j

[Pascal v Vuuren]

My main concern was for the automated building environment, as any given installer will typically only have one developer attending to it and the folder structures are generally the same. However, when building the actual folder will depend on the number of previous builds for that version that have not yet been archived. So it might be D:\Build.700.01, D:\Build.700.02, etc.

However, I see you can specify a command line constant file, which will replace any of the defined constants with the values from the file. That simplifies matters greatly.

Thank you for the assistance guys.

[kcfischer]

I am trying to do the same thing with SUFI. Does any of this apply and if so where do you set these constants? The menu structure is not the same and I haven't found a place that seems to work.

Thanks,

Ken

[jassing]

I am trying to do the same thing with SUFI. Does any of this apply and if so where do you set these constants? The menu structure is not the same and I haven't found a place that seems to work.

Thanks,

Ken

Sort of; however it's not the same.
$(var.ProjectFolder) in SUFWI would be the same as #PROJECTFILEDIR# in suf7

In SUFWI's help -- look at the topic "Global Build Variables" for more information.

[Lorne]

It's also worth noting that relative paths are supported in SUFWI (relative to the location of the .sufproj file).

[kcfischer]

Thanks. I found the reference to file paths being relative to the project folder in the release notes. For anyone else reading this in the furture. If you have a Files subfolder that sits just below your SUFI project file, use Files for the path to the file (no backslash or variable name needed)

Still working through the details on the bootstrapper, but I think I can set this up so it will work on our build machines.

Thanks for the help!

Ken