Specifying relative paths for scripts and output

[Gareth Owen]

Our build system can be located in any directory on the build computer (depends on version)

In most cases, including all the files, we have set up to use a compiler variable to specify the root directory of the source files.

I have found a couple of issues however with some of the other parts of the build.

1) when i specify the output directory using a compiler variable, the build works fine, but if you try to debug the script it stops saying you need to generate a debug build (I have already build an uncompressed version).
If i hardcode the output directory to the same as the compiler variable, it works fine.

2) included scripts
Our build uses a couple of included scripts that we have written, these are located in the same directory as the main script.
If you edit the mpr file and remove the path for these scripts it opens without a problem, but every time you save the project, the absolute path is saved back in for the script location.

It is not a huge problem at the moment, but as our next release gets closer it will become more so as we will need to keep 2 seperate installations synchronised.

Cheers

[MichaelNesmith]

Hi Gareth!

Both behaviors are as designed. I will pass these as feature recommendations to the product team.

[Thona]

I want to add my voice to this. We, too, run into a similar situation (not tried out). While developers do work from a standard hierarchy (too many idiotic tools around that ignore relative paths, plus it is much easier to send hyperlings between people) build can be done from different locations. The next iteration of our system probably will do them from more or less random locations (directory with a GUID). THe reason for this is twofold: once, it blocks developers from using cross-product-references, second - it allows us to run multiple builds on the same product at the same time. That gets handy for documentation, which takes half an hour to generate and is single-threaded, CPU bound - on a machine with 4 cores we could easily start 4 processes.

There is a third version, in that we separate Major.Minor versions of a product (we use the term as it can theoretically encompass multiple solutions) in different paths. Hardcoded paths get in the way fof our upgrade story - when we start, for example 1.3 of a product, it is a branch from 1.2 (because 1.2 most often stil lsees active development for some time, possibly bug fixing for quite a long time). Having to redo all file references is not nice then, either.

Source control would also be extremely nice..

[MichaelNesmith]

Hi Thona

Rest assured we are listening - and implementing - all user feature requests. Soon we will also have an online feature request system where you will be able to enter, and monitor the status of, your feature requests.

[Thona]

I know that

I just wanted to point out my reasoning for that. I found that feature requests with a clear and understandable reason behind them make things a lot more usable.