Configuration Path for created executable (on RAM disk to avoid SSD wear)

[tudi_x]

hi All,
ever since i managed to switch to SSDs i am thinking about SSD wear. an executable with debug message can easily go to 100 MB.
given this if i compile 10 times per hour that is around 8 GB written daily on my 60 - 80 TB lifespan SSD.
i was thinking on having the ability to use a configurable for all compilations path (path that would be actually served by a RAM disk).
now i have to go to each app and modify the path option to point to the RAM disk.

what do you guys think about this option?
thank you

[marcov]

hi All,
ever since i managed to switch to SSDs i am thinking about SSD wear. an executable with debug message can easily go to 100 MB.
given this if i compile 10 times per hour that is around 8 GB written daily on my 60 - 80 TB lifespan SSD.
i was thinking on having the ability to use a configurable for all compilations path (path that would be actually served by a RAM disk).
now i have to go to each app and modify the path option to point to the RAM disk.

what do you guys think about this option?

80TB/8GB = 10000 days = 30 years. What was the problem again ? 

[tudi_x]

i will try another scenario then.   

what about compiling always on the ramdisk because the hard drive access is slower than my RAM? raid 1 for example or 5400rpm...
obviously i cannot keep my code on the ramdisk but i can launch the executable for testing from the ramdisk. eventually even for a 1 bit write there is mechanical wear in the hard drive, but ramdisk is more about electricity - no wear.   

[tudi_x]

refining the suggestion. the option could be having a list of paths.
Lazarus should ignore the path that is not accessible (if more than one path is available compile on first).
this way this list of paths could easily serve multiple platforms on which the user compiles.

right now if i want to compile in a specific location on windows, when moving to linux i need to reconfigure this path.
going back to windows this reconfiguration repeats each time i want to compile the code on the linux platform.

what do you guys think?

thank you

[dogriz]

I use crosscompiling and configure different build modes for linux, linuxARM, windows32 - might be simpler for you than having multiple OSes. For every build mode you can configure different path and other params.
All the coding, compiling and crosscompiling is done on Linux OS - you can put path to the /dev/shm (predefined RAM drive on Debian and forks).

[Eugene Loza]

I think you might use command-line FPC compiler for that purpose. You may also (to some lesser extent use PROJECT>PROJECT OPTIONS>COMPILER OPTIONS> and change Unit path and update "target filename" with a relative directory.

Making an executable run in a "separate than project's files" location is prone to some complex issues.
E.g. I have a game which data folders total size is 110 Mb. Should I copy all these folders to RAM each time? How much time would I waste forgetting to do so? Moreover, my game includes a game data editor, so, how much time will I loose by forgetting to copy the DATA folder back to HDD only once after a significant improvement has been made? Well... I'd better wait for compilation 2 seconds more
The consequences might be really unexpected and ambiguous, suitable only for very simple tasks (e.g. making an executable that doesn't require any additional files). So, I'd leave this option for those who understand all the issues and the risk. I don't think I'd ever use it myself.

[marcov]

Can't you simply already do this by defining a global macro and putting it in the unit and exe paths of the relevant projects?

Then all generated data goes to them, and it is tied to the IDE, not the projects.