Creating a new EDA package

[alexanderbrevig]

I find it curious that on a forum where people regularly spend a lot of time fiddling with parametric searches, reading datasheets and messing about with various mcu toolchains - compiling a tool is a huge hurdle...?

If you want to check out what looks like a lot of work I'm sure you'd be willing to install one tool and run less than ten commands? I'll take that over a closed source unsigned binary any day of the week!

[MarkS]

I find it curious that on a forum where people regularly spend a lot of time fiddling with parametric searches, reading datasheets and messing about with various mcu toolchains - compiling a tool is a huge hurdle...?

If you want to check out what looks like a lot of work I'm sure you'd be willing to install one tool and run less than ten commands? I'll take that over a closed source unsigned binary any day of the week!

I am fully capable of compiling a program downloaded from git. However, there seems to be this push within the open source community, at least for hobby projects, of forcing a Linux-like environment across all supported platforms. I typically avoid Linux due to it's reliance on using the console. I have a very bad memory and cannot remember all of the commands/directories/etc. There is no reason to do this on Windows as Windows gives the same functionality in GUI form. Considering that this project is an attempt to make a EDA program with a more up to date GUI, I find the reliance on a console to be rather odd.

If you're going to write cross-platform tools, you need to take advantage of the platform you are targeting, not force the platform you're familiar with on all platforms you're supporting.

[alexanderbrevig]

I'm sure he will package it when it's user ready. My take on the state of this project is that it still is mostly for the extra interested. Beta testers?
It's entirely possible to build a native windows app: https://www.eevblog.com/forum/eda/new-work-in-progress-eda-package!/msg1139972/#msg1139972

Seems he's put up some binaries for the interested btw; http://0x83.eu/horizon/   

[MarkS]

I have the binaries. They are unusable without first entering console commands to initialize this "pool" thing. Totally unnecessary.

[Zom-B]

The first experimental applications I typically make, you first have to edit a source file to change 'hardcoded' paths before you're able to run it. YYou don't even call this 'rough edges' because it's only edges. It's not a finished product and I trust that the finished one runs equally well on most platforms without console interaction.

[Lukas]

The first experimental applications I typically make, you first have to edit a source file to change 'hardcoded' paths before you're able to run it. YYou don't even call this 'rough edges' because it's only edges. It's not a finished product and I trust that the finished one runs equally well on most platforms without console interaction.

Got me Not too long ago the pool path has been hardcoded to be relative to the current directory. An environment variable then was the easiest way to make it somewhat easy to configure.

[alexanderbrevig]

Maybe a good compromise would be to first look for ENV and if it's not set; use a convention based relative path?
So, if you don't want or need the pool to live in a special place, then it can just be where you want it?

[Zom-B]

Best store it in a configuration file.

Speaking of which, the best way is to first look for the configuration file in the local path (if found, assume portable installation), then look for it in the user profile. If still not found, create one in either location (I don't think there's a standard for assuming portable or non-portable when neither is conclusive).