|
|
|
Home » Developing U++ » U++ Developers corner » Things we want from Linux/FreeBSD release archives
| Things we want from Linux/FreeBSD release archives [message #53378] |
Tue, 31 March 2020 17:52  |
 |
mirek
Messages: 14255
Registered: November 2005
|
Ultimate Member |
|
|
I am starting this new thread to gather ideas about how to improve current Linux tarballs.
Here is my list:
- automatic dependencies installation - detect existence of apt-get / yum / zypper / pacman, perhaps even distro, install things during setup. If that fails, make user aware and ask if script should continue
- 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
|
|
|
|
| Re: Things we want from Linux/FreeBSD release archives [message #53381 is a reply to message #53378] |
Tue, 31 March 2020 20:46  |
|
|
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.
Quote:- use 7z (or at least zip), stop changing the name, just single "upp" folder
What's wrong with *.tar.gz? Or *.tar.xz which is actually what every major distro starts to use lately... The 7z extractor is not installed by default on many distributions (checked on Arch and Debian), so it is not really linux friendly...
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.
Quote:- 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).
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 uses XDG Base Directory specification. So the Makefile in the source package should set the necessary XDG_* environment variables to some local directory, e.g. upp/build/.
Quote:- ship with umks and use it if possible. If not, use Makefile to create umk
Better not put it directly into the source package. Downloading it during the process if needed is IMHO better. The Makefile could also optionally support to use already existing umk (autodetecting it's presence on $PATH or by explicit configuration option).
Few more points I would like to suggest:
- 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 ./configure # this might not even be needed
make
make install
This is what most experienced user will try even before reading the README file. Which reminds me: there should be a README file Also, the "make install" part should honour the standard $DESTDIR and $PREFIX variables, to make it easier for packagers.
Best regards,
Honza
|
|
|
|
| Re: Things we want from Linux/FreeBSD release archives [message #53386 is a reply to message #53381] |
Tue, 31 March 2020 23:24 |
|
mirek
Messages: 14255
Registered: November 2005
|
Ultimate Member |
|
|
dolik.rce wrote on Tue, 31 March 2020 20:46Hi 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.
Well, in general, I just mean there should be quick and easy way to get U++ running.
There should still be Makefile and "normal" way.
Quote:- use 7z (or at least zip), stop changing the name, just single "upp" folder
What's wrong with *.tar.gz? Or *.tar.xz which is actually what every major distro starts to use lately... The 7z extractor is not installed by default on many distributions (checked on Arch and Debian), so it is not really linux friendly...
[/quote]
tar.gz compression sucks. LZMA seems to produce archives that are about 50% of size. But tar.xz is probably better than 7z.
Quote:
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.
I mean that file name can be basically the same (withou x11), but after unpacking, it should be just upp
Quote:
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
By not moving around I am actually thinking about putting everything to that "upp" folder after unpacking. Keep it "sandboxed", no writes outside that dir.
Quote:
- 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).
Well, they are needed during make unfortunately... The logic would need to move to compile phase.
I think most of those MB are screenshot in documentation. Perhaps redoing them with "Gray" theme would help. Or using jpg compression.
Quote:
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 ).
TCore is not present for a long time now...
Quote:
- 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
Well, after changes I am planning I do not even know not only what ./configure would do, but even what make install is supposed to do.
After make, you get theide. Start theide and it configures itself.
Also, not really about release archive, but I think I will add nightly scrip that will add Makefile to svn so that it is buildable from git page.
Mirek
|
|
|
|
| Re: Things we want from Linux/FreeBSD release archives [message #53390 is a reply to message #53381] |
Wed, 01 April 2020 06:30 |
Novo
Messages: 1430
Registered: December 2006
|
Ultimate Contributor |
|
|
dolik.rce wrote on Tue, 31 March 2020 14:46since 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
I vote for the XDG-Based directory structure.
It would be also great if ".upp" (or .config/upp) directory would be changeable. This should allow to create company/project specific configuration directories.
Regards,
Novo
|
|
|
|
| Re: Things we want from Linux/FreeBSD release archives [message #53391 is a reply to message #53390] |
Wed, 01 April 2020 07:32 |
|
|
Novo wrote on Wed, 01 April 2020 06:30A quick question. Since when U++ is using XDG Base Directory specification?
In my local build all configuration files are located in ~/.upp
Since about 2010 Unfortunately it is only used in some functions, e.g. GetDesktopFolder(). See Core/App.cpp for more examples... It should be relatively easy to use it also in GetHomeDirectory(), ConfigFile() and other functions.
Honza
|
|
|
|
| Re: Things we want from Linux/FreeBSD release archives [message #53399 is a reply to message #53391] |
Wed, 01 April 2020 11:07 |
|
mirek
Messages: 14255
Registered: November 2005
|
Ultimate Member |
|
|
So I would like this:
static String sConfigFolder;
void SetConfigDirectory(const String& s)
{
sConfigFolder = s;
}
String ConfigFile(const char *file) {
if(sConfigFolder.GetCount())
return AppendFileName(sConfigFolder, file);
#if defined(PLATFORM_WIN32)
if(sHomecfg) {
String p = GetHomeDirFile(GetExeTitle());
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");
if(DirectoryExists(pp)) {
cfgdir = pp;
break;
}
h = GetFileFolder(h);
}
if(IsNull(cfgdir))
cfgdir = GetEnv("XDG_CONFIG_HOME");
if(IsNull(cfgdir) || !DirectoryExists(cfgdir))
cfgdir = GetHomeDirFile(".config");
}
String pp = AppendFileName(cfgdir, GetAppName());
RealizeDirectory(pp);
return AppendFileName(pp, file);
#else
NEVER();
return file;
#endif//PLATFORM
}
[Updated on: Wed, 01 April 2020 11:21] Report message to a moderator |
|
|
|
| Re: Things we want from Linux/FreeBSD release archives [message #53407 is a reply to message #53399] |
Wed, 01 April 2020 18:17 |
Novo
Messages: 1430
Registered: December 2006
|
Ultimate Contributor |
|
|
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.
Regards,
Novo
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Things we want from Linux/FreeBSD release archives [message #53425 is a reply to message #53411] |
Thu, 02 April 2020 19:10 |
Novo
Messages: 1430
Registered: December 2006
|
Ultimate Contributor |
|
|
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.
Regards,
Novo
|
|
|
|
|
|
|
|
| Re: Things we want from Linux/FreeBSD release archives [message #53433 is a reply to message #53428] |
Fri, 03 April 2020 00:32 |
Novo
Messages: 1430
Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Thu, 02 April 2020 14:45Novo wrote on Thu, 02 April 2020 19:33I 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
GetAppName() is used in many places. I haven't check all of them, but this doesn't seem to be a good idea.
Situation with Mac is slightly different. Apps have to be installed into the /Applications, otherwise they won't work correctly, AFAIK.
So, .config has to go somewhere in /Applications/XXX.app/Contents/MacOS/, but in this case ide and umk won't share configuration.
If we want to share stuff, it will go into ~/.config, and this will litter this folder ...
Regards,
Novo
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Apr 25 21:37:19 CEST 2025
Total time taken to generate the page: 0.02914 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
