Mplab X IDE: init at 6.15

[nyadiia]

Description of changes

This is an IDE for embedded devices and microcontrollers from the microchip brand. There are also the needed compilers in this.

Fixes #291504

Things done

mplabx-ide appears to work on the systems that I've tested it with ( including a fresh VM running xfce ) but for some reason it breaks on some other systems, just showing a white box ( elements still work but aren't displayed ). I also need to test this with actual hardware to see if the udev rules need to be implemented. Only the XC16 compiler is working right now ( the others should work fine, just copy paste ).

I would like to move this all into a module eventually so that the syntax looks something like

programs.mplabx = {
  enable = true;
  compilers = {
    xc8.enable = false;
    xc8.package = pkgs.microchip-xc8;
    xc16.enable = true;
    // ...
  };
}

but I am unsure of how to do this atm.

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.
  may have to squash commits

---

Add a 👍 reaction to pull requests you find important.

[nyadiia]

once this is merged remind me to close #291504

[iFreilicht]

once this is merged remind me to close #291504

You can just put Fixes https://github.com/NixOS/nixpkgs/issues/291504 in the description of this PR, that should do the trick.

I would like to move this all into a module eventually so that the syntax looks something like

programs.mplabx = {
  enable = true;
  compilers = {
    xc8.enable = false;
    xc8.package = pkgs.microchip-xc8;
    xc16.enable = true;
    // ...
  };
}

but I am unsure of how to do this atm.

Modules should be on top of the package itself, not a replacement.

Right now, I would suggest to solve this with parameter attributes in pkgs/applications/editors/mplab-x/default.nix. Users that want to customize the installation can do this with an overlay, and you can add a NixOS module with the easy-to-use options later on top of this.

An additional advantage is that it makes this package usable on non-NixOS-systems without additional work.

How you implement this exactly depends on how many compilers there are, how big (in MB) each of them is compared to the base package and if there is a subset that is only rarely used.

For example, sox has enableX attributes that are mostly true by default. So the default package has the highest compatibility, but is also the largest. rsync is configured similarly.

vim-full takes this a step further, by having a features parameter, multiple xSupport parameters, and a config parameter which is supplied via vimUtils.makeCustomizable in all-packages.nix, and allows calling vim-full.customize to change the options without having to specify an overlay.

Another example would be neovim and its accompanying config, though I'm actually uncertain how (or if) the options there actually get to the package.

[iFreilicht]

BTW, new packages have to go into by-name. You can have a look at the output of "check pkgs/by-name", it tells you pretty clearly how to do this.

[nyadiia]

the error while trying to build with nix build .#mplab-x is that …/nixpkgs
error: attribute 'legacyPackages.x86_64-linux.mplab-x.type' does not exist
i'm not sure where to set this

[cormacc]

Excellent - thanks @nyadiia. Re. just showing as a white box on some systems, this sounds like it may be a Java issue common to some WMs (I've encountered it using i3 and sway). The workaround I've found effective is adding the following to my home.nix:

  home.sessionVariables = {
    #Prevents java UIs showing up as a gray window on i3 and sway...
    _JAVA_AWT_WM_NONREPARENTING = 1;
  };

[cormacc]

A comment/question on the packaging of the xc compilers -- as (somewhat unfortunately) owner of a couple of long-running xc16-based projects I've found it's often desirable not to track the latest version of the compiler due to regressions or breaking changes. For example between xc16 versions 1.61 and 1.70 the program memory footprint of one of our projects jumped from 89% to 96% of the available capacity of the target MCU. Similarly, due to comparative stability our production builds of bootloaders often use an older compiler version than the application firmware.

Would it be practical to include a digest of compiler versions and installer checksums in the compiler packages and pass the required version as an option (defaulting to latest or something?).

If there's anything I can do to help with testing or whatever, let me know. I've only started playing with nix recently and had vague intentions of trying to get my head around packaging to address this exact problem -- reliance on microchip tooling has kept me on an arch/nix/home-manager setup rather than nixos for now.

[nyadiia]

i was thinking about something like this, like in the nixos module being able to change what version everything is but i wanted to do it in a more "nix way". these regressions are actually why i'm packaging 6.15 instead of 6.20 because the latter will not detect compilers ( even on a windows system ). passing in the version and hash seems like a good idea though, i'll see if i can try to implement that.

[cormacc]

Hey @nyadiia - finally got some time to poke at this a bit. Stole your draft packages and reworked them as an overlay here, for my own immediate gratification:
https://github.com/cormacc/nix-microchip

All the heavy lifting is your own work, but did implement the multiple-versions-in-one-folder thing for xc16, which might be useful to you.