Generated files are not portable across different computers

[widget-]

I would like to create a project, and I would like others to be able to use the makefile, etc., as-is but I also want to maintain Visual Teensy support so that the makefiles can be generated.

Currently, it makes some parts of the code like this:

# makefile
# [...]
MCU              := imxrt1062

LIBS_SHARED_BASE := C:\Users\Widget\Documents\Arduino\libraries # absolute path to my home directory
LIBS_SHARED      := 
# [...]

// tasks.json
{
  "tasks": [
    {
      "label": "Build",
      "group": {
        "kind": "build",
        "isDefault": true
      },
      "command": "C:/Users/Widget/bin/Visual Teensy/make.exe", // absolute path to where Visual Teensy is installed
      "args": [
        "all",
        "-j",
        "-Otarget"
      ]
    },
// [...]

---

I think most of the Arduino/Teensyduino files have a "standard" installation that would always put them in the same place on everyone's Windows installs at least.

On Windows, you can use ${UserProfile} in makefiles to get the equivalent of C:\Users\Widget, from which you can get the regular Arduino library path.

tasks.json makes references to files that aren't guaranteed to exist on other peoples' computers. Telling people to use their own make.exes might be fine, if it supports searching the path. Otherwise, the binaries provided by Visual Teensy could be bundled into the project, but I could see people not wanting to bundle random third-party binaries.

[luni64]

This would be a very nice feature indeed but I see a few difficulties:

• Arduino supports zip installation which a lot of people use. So, basically the location of Arduino is not known. Thus we don't know the location of the core files, the compiler etc.
• A user can install multiple copies of Arduino, which one to use?
• If the makefile somehow found out the location of Arduino it would need to parse the preferences.txt to find the location of the shared library folder since this is configurable
• etc..

All in all I don't think that it is feasible to let the makefile do all this. However, I could imagine a configuration tool/script which might be called from the makefile, would find out the required locations and store them in some format in .vsteensy. Maybe just small makefile defining the required variables which could be included from the main makefile

That would still bundle some kind of executable (the config tool) with the library but if it can be done as script it might be acceptable?

[luni64]

Here a first (hand-generated) test portable.zip

I moved the makefile into the .vsteensy folder and extracted all user dependent settings into the workspace settings.json.

{
    "vsteensy.make":          "C:/toolchain/VisualTeensy/make.exe",
    "vsteensy.cores":         "C:/Arduino/arduino-1.8.14/hardware/teensy/avr/cores",
    "vsteensy.sharedLibs":    "C:/Users/lutz/Documents/Arduino/libraries",
    "vsteensy.gcc":           "C:/Arduino/arduino-1.8.14/hardware/tools/arm/bin",
    "vsteensy.uploadPJRC":    "C:/Arduino/arduino-1.8.14/hardware/tools",
    "vsteensy.uploadTY":      "C:/toolchain/TyTools"
}

tasks.json uses these setting to pass the information to the makefile:

{
  "tasks": [
    {
      "label": "Build",
      "group": {
        "kind": "build",
        "isDefault": true
      },
      "command": "${config:vsteensy.make}",
      "args": [
        "all",
        "-j",
        "-Otarget",
        "--file=.vsteensy/makefile",
        "LIBS_SHARED_BASE=${config:vsteensy.sharedLibs}",
        "CORES=${config:vsteensy.cores}",
        "GCC_BASE=${config:vsteensy.gcc}",
        "UPL_PJRC_B=${config:vsteensy.uploadPJRC}",
        "UPL_TYCMD_B=${config:vsteensy.uploadTY}"
      ]
    },
    {
      "label": "Clean",
      "group": {
        "kind": "build",
        "isDefault": true
      },
      "command": "${config:vsteensy.make}",
      "args": [
        "--file=.vsteensy/makefile",
        "clean"
      ]
    },
  .....

So, to adapt the project to a user one currently has to change the path's in settings.json. Next step would be to do some config script which finds this information automatically. If it doesn't find it it might point the user to setup.json so that the information can be entered manually.

The user could also place the setting to the user settings file so they would be available for all projects.

Can you give it a try? Feedback? Ideas?