Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » umk static version
Re: umk static version [message #53382 is a reply to message #53363] Tue, 31 March 2020 21:17 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

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 Smile 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? Smile

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
Re: umk static version [message #53384 is a reply to message #53382] Tue, 31 March 2020 22:20 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
dolik.rce wrote on Tue, 31 March 2020 15:17
What do you think?

"Use unique output directory per assembly (append assembly name to output directory)" is missing Smile


Regards,
Novo
Re: umk static version [message #53385 is a reply to message #53325] Tue, 31 March 2020 22:34 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
For testing:

Here is a Makefile that could potentially completely replace all the current build system.

* It uses the temporary HOME hack
* It shows help message if you don't give any argument to make
* It doesn't need domake script anymore

With this Makefile, developer are completely in control of what happen next.
This Makefile is easy to understand, so even developers should be ok with it Twisted Evil .
  • Attachment: Makefile
    (Size: 1.56KB, Downloaded 171 times)
Re: umk static version [message #53392 is a reply to message #53382] Wed, 01 April 2020 08:53 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
dolik.rce wrote on Tue, 31 March 2020 21:17
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 Smile 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? Smile

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


Yes! It would be great. It's more POSIX friendly.
Options to add:

-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

Re: umk static version [message #53394 is a reply to message #53382] Wed, 01 April 2020 09:25 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
dolik.rce wrote on Tue, 31 March 2020 21:17
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 Smile 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? Smile

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


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. I mean, you do not want to write

cp --from=sourcefile.txt --to=targetfile.txt

either, do you? Smile

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.

Finally (and that is a problem with current sources too), the commandline parsing should be shared between theide and umk.

Mirek
Re: umk static version [message #53395 is a reply to message #53392] Wed, 01 April 2020 09:36 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
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?
Re: umk static version [message #53396 is a reply to message #53394] Wed, 01 April 2020 09:44 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
The main argument for using switch like -A -B is to be flexible and POSIX friendly. You don't have to follow strict rules on parameters order anymore.

Those commands are the same:

umk -B GCC.bm -A uppsrc ide
umk -A uppsrc -B GCC ide
umk -A uppsrc ide

It will break old umk script yes... but do we really need to stick with older and weak behavior?
Using umk in production scripts is so common nowadays?

Re: umk static version [message #53397 is a reply to message #53325] Wed, 01 April 2020 10:05 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
mirek wrote on Wed, 01 April 2020 09:36
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...


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.
If not, you end up with config folders everywhere.

Quote:

Quote:

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


You mean build method variable, right?


Yes. Those in GCC.bm for example. So it should be "Overwrite a build method variable value (advanced option)".
For OUTPUT and UPP (variables in .var files) there is -B and -C

Note: GCC.bm should be called CPP.bm. There is not g++ in this config file.

[Updated on: Wed, 01 April 2020 15:06]

Report message to a moderator

Re: umk static version [message #53398 is a reply to message #53397] Wed, 01 April 2020 10:26 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
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).

[Updated on: Wed, 01 April 2020 10:30]

Report message to a moderator

Re: umk static version [message #53400 is a reply to message #53325] Wed, 01 April 2020 12:30 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

Quote:
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.


For -A, somewhat sane default could be to use all directories in parent directory of <package>. That would work out of the box in the unpacked U++ sources to build anything (from ide to examples). It would not work well with custom assemblies like MyApps, but those are probably not build with umk that often.

And for -B there definitely should be a default. If you open TheIDE, you don't have to select build method, one is always already selected (probably the first one found?). Umk could do the same, when no -B is given: look in the config directory, pick first build method it finds. Ideally with warning along the lines of "No build method specified, using 'XYZ' as default. Use -B to specify different method."

Quote:
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.


Yes, I think it would not be too difficult to keep the old way working as well, at least for some time Smile
Re: umk static version [message #53401 is a reply to message #53400] Wed, 01 April 2020 15:38 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
dolik.rce wrote on Wed, 01 April 2020 06:30
It would not work well with custom assemblies like MyApps, but those are probably not build with umk that often.

Well, I wouldn't agree with that. I'm using umk with MyApps all the time. This is my workflow. I'm using TheIDE only when I need debugger.


Regards,
Novo
Re: umk static version [message #53402 is a reply to message #53398] Wed, 01 April 2020 16:20 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
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?
Re: umk static version [message #53403 is a reply to message #53402] Wed, 01 April 2020 16:27 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
Adding the notion of workspace could be interesting: a directory where your store your ide configuration + projects sources and binaries; even if yours projects can reference external sources or data.

[Updated on: Wed, 01 April 2020 16:28]

Report message to a moderator

Re: umk static version [message #53404 is a reply to message #53402] Wed, 01 April 2020 16:54 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
amrein wrote on Wed, 01 April 2020 16:20
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?


Basically yes, with very minor differences: I do not plan to add "-1234" to the package name and spellers will be in $HOME/upp. output will to ~/upp/.cache

Definitely binary package is completely different kind of beast, however I think the proposed solution adapts itself to it quite easily.

Not that things also work nicely if you move theide to e.g. ~/bin - it will start using 'regular' ~/.config and ~/.cache out of box...

BTW, I already have all this working, now trying to put together "demo" release for further discussion.

Mirek
Re: umk static version [message #53405 is a reply to message #53404] Wed, 01 April 2020 16:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
P.S.: You can as well easily achive ~/upp/theide to use ~/.config, ~/.cache : just delete ~/upp/.config and ~/upp.cache...
Re: umk static version [message #53406 is a reply to message #53405] Wed, 01 April 2020 17:59 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
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.

Another thing. IMHO, it would be useful to be able to launch a compiled app using umk. Output directory is different with TheIDE and umk even if build options are similar. That would simplify scripting and testing.

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.


Regards,
Novo
Re: umk static version [message #53412 is a reply to message #53406] Wed, 01 April 2020 20:39 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Novo wrote on Wed, 01 April 2020 17:59
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.


With current umk

- first configuration is selected if you do not specify any flags
- not sure how would you speficy other configuration - the most straighforward is using flags

Quote:

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
Re: umk static version [message #53413 is a reply to message #53412] Wed, 01 April 2020 21:08 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
mirek wrote on Wed, 01 April 2020 14:39
theide actually understands umk commandline

This is what I see:
$ 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".

I can open a project via "ide /path/proj/proj.upp".
This is it.
Am I missing something?

This is not critical, but would be useful ...

I'm composing command line arguments for umk. It would be convenient to use the same set of arguments with theide when I need to debug my code.

At this time I'm able to generate log-file name for a project (this is where all log messages go). I'd like to keep this feature.


Regards,
Novo
Re: umk static version [message #53414 is a reply to message #53412] Wed, 01 April 2020 21:15 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
mirek wrote on Wed, 01 April 2020 14:39

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

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

Something like "umk -C StdAlloc".
IMHO, this is much more convenient than "umk +GUI,MT,USEMALLOC".
And half of my projects define "StdAlloc" as "MT USEMALLOC" ...


Regards,
Novo
Re: umk static version [message #53415 is a reply to message #53414] Wed, 01 April 2020 21:47 Go to previous messageGo to previous message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
Current umk (rev 14206) doesn't search its config in .config/umk and it uses .config/umk/_out as cache dir instead of .cache/upp.out/ Sad

[Updated on: Wed, 01 April 2020 21:48]

Report message to a moderator

Previous Topic: Support for plug-in architecture
Next Topic: How to determine if U++ is being utilized...
Goto Forum:
  


Current Time: Fri Mar 29 10:54:52 CET 2024

Total time taken to generate the page: 0.01913 seconds