detect existence of apt-get / yum / zypper / pacman

- use 7z (or at least zip), stop changing the name, just single "upp" folder

- stop moving things around, stop writing outside "upp" folder - basically same behaviour as Win32 and MacOS. theide will get generated inside unpacked archive and will stay there. I think users can and will move it where they want later. (That said, I am not quite sure at this point about ~/.upp. Easy to do for theide, not so sure about compiled apps).

- ship with umks and use it if possible. If not, use Makefile to create umk

./configure # this might not even be needed
make
make install

Hi Mirek,

Quote:

detect existence of apt-get / yum / zypper / pacman

Good idea, but there should also be a simple way to disable this. This will be appreciated by packagers who would like to create deb/rpm/PKGBUILD/... because in that case the tooling has its own ways to install prerequisites.

- use 7z (or at least zip), stop changing the name, just single "upp" folder

Also I'm not sure what you mean by changing the name, but I'm pretty sure that the "x11" should be dropped from the filename.

Definitely a good idea. I think the proper place for the things currently written in ~/.upp is actually in ~/.config. Also, TheIDE should store compiled object in ~/.cache, since they ca be easily rebuilt. It should be possible to configure it, since U++ already

- Clean the files a bit, before packaging. I think the archive is pretty big and it wouldn't hurt to only include necessary files. E.g. 32MB of tppi could be omitted, as those are automatically created by TheIDE (if I understand it correctly).

Perhaps they should not even be in the repository... There also might be some packages, that are no longer needed or maintained, or could be in separate nest, since they are not needed by regular users (yes TCore, I'm looking at you and your friends ).

- Follow common conventions as much as possible. It should be possible to build it just by running [code]./configure # this might not even be needed
make
make install

since U++ already uses XDG Base Directory specification.

A quick question. Since when U++ is using XDG Base Directory specification?
In my local build all configuration files are located in ~/.upp

Is it possible to add "static String sAppName" in addition to sConfigFolder?
In this case for PLATFORM_WIN32 we will get

String p = GetHomeDirFile(Nvl(sAppName, GetExeTitle()));

And for PLATFORM_POSIX

String pp = AppendFileName(cfgdir, Nvl(sAppName, GetAppName()));

Otherwise we are limited by a name of an executable.

I'm just curious, why are you using GetExeTitle() instead of GetAppName() with WIN32?
This seems to be inconsistent ...

I just realized that I can create my local .config folder, but I still think that it would be useful to have the sAppNamePrefix variable ...

Novo wrote on Thu, 02 April 2020 19:33

I just realized that I can create my local .config folder, but I still think that it would be useful to have the sAppNamePrefix variable ...

Maybe we can just allow slash in AppName and default to ".upp/" + GetExeTitle().

Anyway, I would like more opinions on this. After all, I have moved to .config based on suggestions here...

Mirek

Situation with Mac is slightly different. Apps have to be installed into the /Applications, otherwise they won't work correctly, AFAIK.

My ~/.config gets quickly littered by dozens of my dev apps.
Another problem is conflicting names. ~/.config is a system-wide namespace.

I propose to add a sAppNamePrefix variable in addition to the sAppName.
If it ends with the slash, then it will be a folder. (I propose to make it "upp/" by default)
Without the slash this will be a regular prefix. "upp" -> "upptheide", for example.

If I'm shipping several apps, I can put all configs in one folder, and name it after a company, for example.

Done: SetAppGroup, default is "u++". So unless you use SetAppGroup, all is now stored into .config/u++/GetAppName()

This does affect Mac and Linux apps.

Novo wrote on Sun, 05 April 2020 00:49

This does affect Mac and Linux apps.

What is technical reason of this change?
To be honest I pissed off by changes like this. I have many embedded apps that keep their settings in .upp directory and the last thing I need is to loose their settings, because default ConfigFile() has changed.

Hi

I don't understand why we use ~/.config and ~/.cache and not directories in the current source directory when U++ is inside user home directory.
I mean, the main idea of sandboxing is to keep everything in the same directory, right?

String  ConfigFile(const char *file) {
	if(sConfigFolder.GetCount())
		return AppendFileName(sConfigFolder, file);
#if defined(PLATFORM_WIN32)
	if(sHomecfg) {
		String p = GetHomeDirFile(GetAppName());
		ONCELOCK
			RealizeDirectory(p);
		return AppendFileName(p, file);
	}
	return GetExeDirFile(file);
#elif defined(PLATFORM_POSIX)
	static String cfgdir;
	ONCELOCK {
		String h = GetExeFolder();
		if(!sHomecfg)
			while(h.GetCount() > 1 && DirectoryExists(h)) {
				String pp = AppendFileName(h, ".config");
				FindFile ff(pp);
				if(ff && ff.IsFolder() && ff.CanWrite()) {
					cfgdir = pp;
					break;
				}
				h = GetFileFolder(h);
			}
		if(IsNull(cfgdir))
			cfgdir = GetEnv("XDG_CONFIG_HOME");
		if(IsNull(cfgdir) || !DirectoryExists(cfgdir))
			cfgdir = GetHomeDirFile(".config");
		if(sConfigGroup.GetCount())
			cfgdir = AppendFileName(cfgdir, sConfigGroup);
	}
	String pp = AppendFileName(cfgdir, GetAppName());
	RealizeDirectory(pp);
	return AppendFileName(pp, file);
#else
	NEVER();
	return GetExeDirFile(file);
#endif//PLATFORM
}

Novo wrote on Sun, 05 April 2020 00:49

This does affect Mac and Linux apps.

What is technical reason of this change?
To be honest I pissed off by changes like this. I have many embedded apps that keep their settings in .upp directory and the last thing I need is to loose their settings, because default ConfigFile() has changed.

Zbych wrote on Sun, 05 April 2020 11:12

Novo wrote on Sun, 05 April 2020 00:49

This does affect Mac and Linux apps.

What is technical reason of this change?
To be honest I pissed off by changes like this. I have many embedded apps that keep their settings in .upp directory and the last thing I need is to loose their settings, because default ConfigFile() has changed.

Thinking about it... I can actually change ConfigFile further so that it will use ~/.upp config if it finds it instead of ~/.config.

Do we want that?

Mirek

Ide is still opening log-file from ~/.upp
Although it is stored in .config/u++ now ...

Novo wrote on Mon, 06 April 2020 06:33

Ide is still opening log-file from ~/.upp
Although it is stored in .config/u++ now ...

Have you recompiled it?

Mirek

mirek wrote on Mon, 06 April 2020 04:12

Novo wrote on Mon, 06 April 2020 06:33

Ide is still opening log-file from ~/.upp
Although it is stored in .config/u++ now ...

Have you recompiled it?

Mirek

Double-checked. Full rebuild. Alt-l opens a log-file located in ~/.upp
GIT rev. 74249e7
It is easy to check. Timestamp is "04.04.2020 15:30:37"

Bug in theide, should be now fixed.

Novo wrote on Sun, 05 April 2020 00:49

This does affect Mac and Linux apps.

What is technical reason of this change?
To be honest I pissed off by changes like this. I have many embedded apps that keep their settings in .upp directory and the last thing I need is to loose their settings, because default ConfigFile() has changed.

Another problem with Mac.
It looks like GetExeFolder() doesn't resolve links on Mac.
The way I check that: I created a link to umk in ~/.local/bin
~/.local/bin/umk -> ~/dvlp/cpp/upp/out/uppsrc/CLANG.Blitz.Shared/umk
Config dir is located in ~/dvlp/cpp/upp/
This perfectly works on Linux but Mac.
On Mac I need to create a link to config dir in ~/.local/
I guess the problem is with GetExeFolder() -> GetExeFilePath() ...
Not sure who is supposed to resolve links, OS or Upp ...
Debugger doesn't work on Mac, so, it is a little bit difficult to track an origin of the problem.

Hopefully fixed in the trunk. Looks like BSD magic did not really work in MacOS...