dolik.rce wrote on Mon, 30 March 2020 21:52

One thing I'd definitely change about umk is the "UI". Fixed position parameters, no real help, some params prefixed with '-', some with '+', no long options... Explaining this to a common user would be nightmare Isn't it time to tweak this a little as well? I'd be willing to do the work. I know it's not hard, but I guess you have more important things to do, right?

I any case it would be good to show how do you want to change it before implementing...

Usage:
    umk [options] <package> [<output>]

Arguments:
    <package>       Package name
    <output>        Output file or directory. If omitted, <package> name will be used.

Options:

-A, --assembly <paths>
                    Comma separated paths to source directories or path to .var file.

-B, --build-method <build_method>
                    Build method name or path to .bm file. Default value is 'GCC'.

-f, --flags <FLAGS> Comma separated list of flags. Default value is 'GUI,MT'.

-a, --all           Rebuild all.

-b, --blitz         Use BLITZ.

-v, --verbose       Be verbose.

-l, --silent        Silent mode.

-u, --target        Use target directory.

-m, --map           Create a map file.

-d, --debug=[no|minimal|full]
                    Select debug mode:
                        no      = release mode, full optimizations (default)
                        minimal = no debug symbols, no optimizations
                        full    = with debug symbols, no optimizations

-s, --shared        Use shared libraries.

-S, --all-shared    Use shared libraries and build as shared libraries.

-M, --makefile      Create makefile (to file <output>).

-x, --export        Export project (to directory <output>), export only files used.

-X, --export-all    Export project (to directory <output>), export all files.

-k, --no-delete     Do not delete target directory out when exporting.

-H, --threads <N>   Build using <N> threads. Default is number of logical cores available.

-h, --help          Show this text.

Examples:

    Build release version of TheIDE:
        umk -b -A uppsrc ide ~/theide

    Use custom build method:
        umk -b -A uppsrc -B ~/.upp/theide/CLANG.bm ~/theide

    Rebuild Bombs example in debug mode:
        umk -ab --debug=full -A examples Bombs

    Build Bombs example using source paths
        umk -A upp/examples,upp/uppsrc Bombs

What do you think?

mirek wrote on Mon, 30 March 2020 23:28

dolik.rce wrote on Mon, 30 March 2020 21:52

One thing I'd definitely change about umk is the "UI". Fixed position parameters, no real help, some params prefixed with '-', some with '+', no long options... Explaining this to a common user would be nightmare Isn't it time to tweak this a little as well? I'd be willing to do the work. I know it's not hard, but I guess you have more important things to do, right?

I any case it would be good to show how do you want to change it before implementing...

I was thinking something like this:

Usage:
    umk [options] <package> [<output>]

Arguments:
    <package>       Package name
    <output>        Output file or directory. If omitted, <package> name will be used.

Options:

-A, --assembly <paths>
                    Comma separated paths to source directories or path to .var file.

-B, --build-method <build_method>
                    Build method name or path to .bm file. Default value is 'GCC'.

-f, --flags <FLAGS> Comma separated list of flags. Default value is 'GUI,MT'.

-a, --all           Rebuild all.

-b, --blitz         Use BLITZ.

-v, --verbose       Be verbose.

-l, --silent        Silent mode.

-u, --target        Use target directory.

-m, --map           Create a map file.

-d, --debug=[no|minimal|full]
                    Select debug mode:
                        no      = release mode, full optimizations (default)
                        minimal = no debug symbols, no optimizations
                        full    = with debug symbols, no optimizations

-s, --shared        Use shared libraries.

-S, --all-shared    Use shared libraries and build as shared libraries.

-M, --makefile      Create makefile (to file <output>).

-x, --export        Export project (to directory <output>), export only files used.

-X, --export-all    Export project (to directory <output>), export all files.

-k, --no-delete     Do not delete target directory out when exporting.

-H, --threads <N>   Build using <N> threads. Default is number of logical cores available.

-h, --help          Show this text.

Examples:

    Build release version of TheIDE:
        umk -b -A uppsrc ide ~/theide

    Use custom build method:
        umk -b -A uppsrc -B ~/.upp/theide/CLANG.bm ~/theide

    Rebuild Bombs example in debug mode:
        umk -ab --debug=full -A examples Bombs

    Build Bombs example using source paths
        umk -A upp/examples,upp/uppsrc Bombs

What do you think?

Honza

-c, --config <path>
                    Path to configuration files (default ~/.upp/umk).

-C, --cache <path>
                    Path to cache directory (default ~/.upp/umk/_out).

-e, --define <variable="value">
                    Overwrite an internal config value (advanced option).

Examples:

Build Bombs example using var paths and define a different cache location
        umk -A examples.var -C $PWD/build Bombs


Build Bombs example using GCC build method but with a different compiler name
        umk -A upp/examples,upp/uppsrc -e COMPILER="gcc-42" Bombs

mirek wrote on Mon, 30 March 2020 23:28

dolik.rce wrote on Mon, 30 March 2020 21:52

One thing I'd definitely change about umk is the "UI". Fixed position parameters, no real help, some params prefixed with '-', some with '+', no long options... Explaining this to a common user would be nightmare Isn't it time to tweak this a little as well? I'd be willing to do the work. I know it's not hard, but I guess you have more important things to do, right?

I any case it would be good to show how do you want to change it before implementing...

I was thinking something like this:

Usage:
    umk [options] <package> [<output>]

Arguments:
    <package>       Package name
    <output>        Output file or directory. If omitted, <package> name will be used.

Options:

-A, --assembly <paths>
                    Comma separated paths to source directories or path to .var file.

-B, --build-method <build_method>
                    Build method name or path to .bm file. Default value is 'GCC'.

-f, --flags <FLAGS> Comma separated list of flags. Default value is 'GUI,MT'.

-a, --all           Rebuild all.

-b, --blitz         Use BLITZ.

-v, --verbose       Be verbose.

-l, --silent        Silent mode.

-u, --target        Use target directory.

-m, --map           Create a map file.

-d, --debug=[no|minimal|full]
                    Select debug mode:
                        no      = release mode, full optimizations (default)
                        minimal = no debug symbols, no optimizations
                        full    = with debug symbols, no optimizations

-s, --shared        Use shared libraries.

-S, --all-shared    Use shared libraries and build as shared libraries.

-M, --makefile      Create makefile (to file <output>).

-x, --export        Export project (to directory <output>), export only files used.

-X, --export-all    Export project (to directory <output>), export all files.

-k, --no-delete     Do not delete target directory out when exporting.

-H, --threads <N>   Build using <N> threads. Default is number of logical cores available.

-h, --help          Show this text.

Examples:

    Build release version of TheIDE:
        umk -b -A uppsrc ide ~/theide

    Use custom build method:
        umk -b -A uppsrc -B ~/.upp/theide/CLANG.bm ~/theide

    Rebuild Bombs example in debug mode:
        umk -ab --debug=full -A examples Bombs

    Build Bombs example using source paths
        umk -A upp/examples,upp/uppsrc Bombs

What do you think?

Honza

-c, --config <path>
Path to configuration files (default ~/.upp/umk).

-C, --cache <path>
Path to cache directory (default ~/.upp/umk/_out).

-e, --define <variable="value">
Overwrite an internal config value (advanced option).

amrein wrote on Wed, 01 April 2020 08:53

-c, --config <path>
Path to configuration files (default ~/.upp/umk).

-C, --cache <path>
Path to cache directory (default ~/.upp/umk/_out).

I would like to change these defaults here. My current idea, maybe wrong, is that U++ will scan folders from the one where binary is up to root and tries to find ".config" (or .upp, not quite decided yet). Only if it does not find one, it would use ~/.upp/umk or ~/.config/umk.

Alternatively (or additionally), I can imagine that umk can easily run without configuration files...

Quote:

-e, --define <variable="value">
Overwrite an internal config value (advanced option).

You mean build method variable, right?

amrein wrote on Wed, 01 April 2020 10:05

I would like to change these defaults here. My current idea, maybe wrong, is that U++ will scan folders from the one where binary is up to root and tries to find ".config" (or .upp, not quite decided yet). Only if it does not find one, it would use ~/.upp/umk or ~/.config/umk.

Alternatively (or additionally), I can imagine that umk can easily run without configuration files...

It's better to use default config folder on Windows, Linux or Mac and have the opportunity to define your own config folder for package sandboxing.

I believe that -A as option does not make much sense. What will umk do if you do not specify -A? Probably the same for -B.

Also, it would really be good if the new interface was backward compatible, as not to break exiting scripts (not only mine, but I know that there are users that depend on umk). I think making '+' synonyme of '-f', perhaps even hidden, should not cause any problems.

It would not work well with custom assemblies like MyApps, but those are probably not build with umk that often.

Quote:

amrein wrote on Wed, 01 April 2020 10:05

I would like to change these defaults here. My current idea, maybe wrong, is that U++ will scan folders from the one where binary is up to root and tries to find ".config" (or .upp, not quite decided yet). Only if it does not find one, it would use ~/.upp/umk or ~/.config/umk.

Alternatively (or additionally), I can imagine that umk can easily run without configuration files...

It's better to use default config folder on Windows, Linux or Mac and have the opportunity to define your own config folder for package sandboxing.

Not sure about Linux/Mac, but after 15 years of trying various things, current approach used in Windows is far the best. That is: everything is stored in the same folder you get after unpacking the archive.

Using default config folder (like ~/.config) has various disadvantages compared to this simplistic approach. E.g. you cannot have two isolated U++ variants at the same time. If you delete U++ folder, you still have remnants in ~/.config. Etc...

So yes, my personal preference for improvement here is to sandbox it.

Now the suggested mechanism is not quite elegant. It is just the first approach that came to my mind to solve the problem in a way to keep things sanboxed while allowing normal ~/.config too (developed application would be normally produced to upp/out, so would pick upp/.config as well; when installed elsewhere, these would default to standard ~/.config).

mirek wrote on Wed, 01 April 2020 10:26

Quote:

amrein wrote on Wed, 01 April 2020 10:05

I would like to change these defaults here. My current idea, maybe wrong, is that U++ will scan folders from the one where binary is up to root and tries to find ".config" (or .upp, not quite decided yet). Only if it does not find one, it would use ~/.upp/umk or ~/.config/umk.

Alternatively (or additionally), I can imagine that umk can easily run without configuration files...

It's better to use default config folder on Windows, Linux or Mac and have the opportunity to define your own config folder for package sandboxing.

Not sure about Linux/Mac, but after 15 years of trying various things, current approach used in Windows is far the best. That is: everything is stored in the same folder you get after unpacking the archive.

Using default config folder (like ~/.config) has various disadvantages compared to this simplistic approach. E.g. you cannot have two isolated U++ variants at the same time. If you delete U++ folder, you still have remnants in ~/.config. Etc...

So yes, my personal preference for improvement here is to sandbox it.

Now the suggested mechanism is not quite elegant. It is just the first approach that came to my mind to solve the problem in a way to keep things sanboxed while allowing normal ~/.config too (developed application would be normally produced to upp/out, so would pick upp/.config as well; when installed elsewhere, these would default to standard ~/.config).

Let says we do just this. So we will have two user cases:

1. Source package

* We extract and compile theide and umk
* We create our own projects in the same directory (in $HOME/upp-1234/MyApps for example)
* theide uses the current $HOME/upp-1234/uppsrc and $HOME/upp-1234/config/upp/theide directories when it starts from $HOME/upp-1234/
* theide uses spellers from $HOME/upp-1234/config/theide/speller/
* We can checkout upp svn sources there (in $HOME/upp-1234/svn) or elsewhere using theide (if needed)
* theide and umk use $HOME/upp-1234/build.out as shared cache directory

2. Binary package (in /usr or /opt)

* theide and umk are in a read only directory ($bindir)
* We create our own projects somewhere else, in $HOME/upp-src/MyApps for example
* theide checkout upp svn sources in $HOME/upp-src/svn/ and uses it configs from $USER/.config/upp/theide directories
* theide uses spellers from $USER/.config/upp/theide/speller/
* theide and umk use something like $HOME/upp-src/build.out as cache directory (or /var/tmp/upp/build.out/ or /tmp/upp/build.out/)

Is that correct?

I'm probably missing something, but I do not see a way to set configuration from mainconfig with umk.
Setting of individual flags is useful, but selecting a predefined configuration is much easier.

One more thing. IMHO, it would be useful to be able to pass similar options to TheIDE. Not just a project, but also configuration and build method.

theide actually understands umk commandline

$ ide -h
Usage: theide -f [file..]
       theide [file..] // autodetection mode

Common options:
    -v or --version - displays information about version.
    -h or --help    - displays this site.

Advanced options:
    --scale $percent - scale interface by "percent" parameter.

Internal options (Should not be called by the user):
    --gdb_debug_break_process $pid - breaks debug process represented by "pid".

- not sure how would you speficy other configuration - the most straighforward is using flags

mainconfig
	"Default" = "GUI MT",
	"StdAlloc" = "GUI MT USEMALLOC";