Fix structure of directories #2

Birleştirildi
SlavekB 6 yıl önce feat/dirsStructure içindeki 1 işlemeyi master ile birleştirdi
SlavekB 6 yıl önce yorum yaptı
Sahibi

Following the observation from @cethyel mentioned in #1, I prepared a proposal to fix structure of directories.

Following the observation from @cethyel mentioned in #1, I prepared a proposal to fix structure of directories.
SlavekB PR/rfc etiketini 6 yıl önce ekledi
Ghost 6 yıl önce yorum yaptı

automake and cmake work both the same way here (minus the man page with automake, which is correct).

minor remark, the "icon" directory could be branded plurial since these icons go into INSTALL_PREFIX/share/icons

<< hijack here! >> I'll profit from this proposal to go further (not for this package though):
I actually wish to change the structure for some since there is inconsistency amongst several packages.
I didn't know what to do with the desktop files (*.desktop), I though about putting them in a "resources" or "misc" folder.
Basically the ideas is to keep clean the first level of hierarchy in the packages with only the build system and info files related to the building.
In addition to this, I'd like to have a "src" folder with only code files to process as binaries (some png files are processed into headers to be embeded for example) ; if we see png files in the src folder, that's means they will be processed not copyed.

How about this hierarchy:

  • doc/{en,man}
  • translations
  • src/{prog1,prog2,prog3,commonlib}
  • resources/{icons/pics/*.desktop}
automake and cmake work both the same way here (minus the man page with automake, which is correct). minor remark, the "icon" directory could be branded plurial since these icons go into INSTALL_PREFIX/share/icons << hijack here! >> I'll profit from this proposal to go further (not for this package though): I actually wish to change the structure for some since there is inconsistency amongst several packages. I didn't know what to do with the desktop files (*.desktop), I though about putting them in a "resources" or "misc" folder. Basically the ideas is to keep clean the first level of hierarchy in the packages with only the build system and info files related to the building. In addition to this, I'd like to have a "src" folder with only code files to process as binaries (some png files are processed into headers to be embeded for example) ; if we see png files in the src folder, that's means they will be processed not copyed. How about this hierarchy: - doc/{en,man} - translations - src/{prog1,prog2,prog3,commonlib} - resources/{icons/pics/*.desktop}
SlavekB 6 yıl önce yorum yaptı
Poster
Sahibi

I hesitated if icon or icons. But because here is the only one icon of the program (even in multiple sizes), I chose icon. That the target folder is icons is not as important as there are multiple program icons in the target folder. But you are right that we could modify other applications in a similar way, and using icons would in this case be a better choice.

Finding a consensus to unify application directory structure is definitely a good idea. Now the folder is sometimes src, sometimes the name of the application, sometimes even the application name including the version number. Translations are mostly in po, sometimes translations, sometimes po within src, ... it is very diverse. For discussion, we can either use a mailing list or create an issue on the master TDE/tde module.

I hesitated if `icon` or `icons`. But because here is the only one icon of the program (even in multiple sizes), I chose `icon`. That the target folder is `icons` is not as important as there are multiple program icons in the target folder. But you are right that we could modify other applications in a similar way, and using `icons` would in this case be a better choice. Finding a consensus to unify application directory structure is definitely a good idea. Now the folder is sometimes `src`, sometimes the name of the application, sometimes even the application name including the version number. Translations are mostly in `po`, sometimes `translations`, sometimes `po` within `src`, ... it is very diverse. For discussion, we can either use a mailing list or create an issue on the master [TDE/tde](../tde/issues) module.
MicheleC 6 yıl önce yorum yaptı
Sahibi

We could use Etherpad for discussion, it is easier than issue I think. Multiple people can simply edit inline

We could use Etherpad for discussion, it is easier than issue I think. Multiple people can simply edit inline
Ghost 6 yıl önce yorum yaptı

Works for me, with both automake and cmake.

Works for me, with both automake and cmake.
SlavekB PR/rfc etiketini 6 yıl önce sildi
SlavekB 6 yıl önce değişiklik isteğini kapattı
SlavekB feat/dirsStructure dalı silindi 6 yıl önce
SlavekB 6 yıl önce R14.0.6 release kilometre taşına ekledi
Değişiklik isteği 06772a369f olarak birleştirildi.
Bu konuşmaya katılmak için oturum aç.
Değerlendirici yok
Kilometre Taşı Yok
Atanan Kişi Yok
3 Katılımcı
Bildirimler
Bitiş Tarihi

Bitiş tarihi atanmadı.

Bağımlılıklar

Bağımlılık yok.

Referans: TDE/knetstats#2
Yükleniyor…
Henüz bir içerik yok.