search

the-carlisle-group / Acre-Desktop

A simple Dyalog APL IDE plugin that introduces "projects" and allows you to keep your source code in Unicode text files.
MIT License
11 stars 1 forks source link

Acre build function should put the release into a /dist folder #66

Closed norberturkiewicz closed 5 years ago

norberturkiewicz commented 6 years ago

The /dist folder should also be part of the .gitgnore file.

This way we can always build a working version of Acre-Desktop, from the source, not worrying about overwriting anything.

image image

Also, can we update the Readme with instructions on building a ws from the source?

PaulMansour commented 6 years ago

I'd like to think a little about the name of this folder, or at least reserve the right to rename it. It seems that it is effectively the "Release", and perhaps that is a better name. Every project will or should have this folder.

PhilLast commented 6 years ago

Since user commands were first added to acre-2 it has associated the folder as a source of user commands using the Settings "CMDDIR" property. This has had problems for many years concerned with a mis-match between the SALT code and the GUI.

Since acre-3 became entirely user-command based the CMDDIR setting is the only deliberate reference to acre in the windows registry and other OSs equivalent - thus is the main step in acre's installation which attempts to remove all previous acre CMDDIR settings by analysis of the present settings on the assumption that they will have the same name and that other sources of user commands will not. That name is conventionally "acre" but is actually the name of the folder from which the Install function, ultimately the workspace, has been loaded. Thus if the acre installation is copied to another location, given a different name and Install run thence, both sources will exist and I can't predict which one would be used. This is one source of problems already encountered.

Giving the acre folder a name that is likely to be used by other systems installing user commands is inviting a further set of problems.

If three systems installed user commands from: /systemA/dist/, /systemB/dist/ and /systemC/dist/ and one of those systems were acre its current method of installation would simultaneously remove the other two.

This is not to say that the current method is the best possible method. It's just the only one I've tried and by-and-large it works.

The only "improvement" I can think of that doesn't bring with it a whole lot of new problems other than having the user manually edit the CMDDIR setting is an ]acre.UnInstall command to be run from the old before installing the new.