Discussion: Build system improvements

[nathan818fr]

I have already sent some pull requests regarding the build system. I would like to continue this way to simplify the system, and I would like to have your opinion / validation before starting:

1. Variants management:

   • Creating a single datasource for the management of variants, eg. an array of objects that would contain all variables of the variant:

     
     # (code concept)

   themes definition

   themes = [] foreach variant : get_option('variants') foreach transparency : get_option('transparency')

   transparency could be transformed into an array to build the normal and solid variants in a single run

   name = 'Arc' + variants_names.get(variant) + (transparency ? '-solid' : '')

   themes += { 'name': name, 'dir': datadir / 'themes' / name, 'variant': variant, 'transparency': transparency,

   more variables could be added easily

   } endforeach endforeach

   then usage

   foreach theme : themes install_data(XXX, rename: 'index.theme', install_dir: theme['dir']) endforeach

2. Index files:

   • Using a single index.theme.in file, with a variable for the theme name
   • Therefore moving this index.theme.in directly to common/

3. SASS code generation:

   • Using, whenever possible, a single input file for sass generation (eg. for gtk3 a gtk.scss.in file containing themes variants variables).

[jnsh]

Sorry about the late reply..

1. Variants management:

   * Creating a single datasource for the management of variants, eg. an array of objects that would contain all variables of the variant:

Is the goal to merely simplify the code without any practical changes, or do you wish to allow building all variants (i.e. transparent and *-solid variants) simultaneously?

2. Index files:

   * Using a single index.theme.in file, with a variable for the theme name
   * Therefore moving this index.theme.in directly to common/

3. SASS code generation:

   * Using, whenever possible, a single input file for sass generation (eg. for gtk3 a `gtk.scss.in` file containing themes variants variables).

These I've had in mind myself, and they should be fairly simple to implement. PRs are welcome :)

[jnsh]

Items 2. and 3. were implemented in https://github.com/jnsh/arc-theme/commit/860860cdd5479fdb3208fd62a32de71c98c71b2d and https://github.com/jnsh/arc-theme/commit/a7f60904f8b8aba1706a1e7fbbe29093a30c8163.

I'm still not sure about the main purpose of 1. I see it would allow building transparent and non-transparent simultaneously. However, I think that's generally not beneficial for users building the theme for themselves, since they would most likely just want one of the two options.

This could be useful for distro packages, as they could build both options simultaneously. However since the transparency has always been separately built option, packagers have already adapted to this however they see best, and changing it would only cause extra work.

Closing, since this seems to be abandoned anyway.