Hi,
As explained earlier, the new command-line options are first based on the
mstsc options, from which we extend to add all our options.
You can find the mstsc command-line reference here:
I'm not overly fond of the existing command line structure, but i'm
also not desiring necessarily to have an MSTSC compatible command
line structure, either.
I do understand the desire to have an MSTSC compatible interface, so
why not just create a front-end converter to translate the options
Using a Microsoft style command line syntax for a Linux program really doesn't
make sense. I think that it would be best to drop the MS style arguments from
Linux. It's too difficult to get the parsing right.
For example /admin is a legal file name. How can you tell whether
it is a
I fail to comprehend the need or utility for the change. Perhaps leave the
existing POSIX syntax for xfreerdp and create this new-fangled syntax for
wfreerdp. You can, and already have, been a lot more clever than the MS
reference documentation.
Hi Kevin,
The current syntax detection method is very naive and can simply be
replaced by a much better one that will work with much more accuracy. For
instance, we know what the expected options are, one very accurate way
would be to parse the argument vector twice, one for each syntax, and
Hi Marc- Andre,
I don't want to discourage you from the excellent work you are doing. However,
I want to
make sure that you are cautious.
Any method which uses heuristics is subject to error in certain cases. Counting
the number of arguments will reduce the errors,
but when errors happen,
On 4 Dec 2012, at 18:07, Kevin Dalley wrote:
Please don't use argv[0] to determine the behavior. This is confusing.
It should be possible to make a link to a program and have it behave in
the same way as the original program.
Also, it violates the GNU standards.
Alex,
The two of use agree on most issues here.
Heuristics, no.
Pre-existing parsers, yes. I prefer argp, because it includes
documentation.
We do disagree n argv[0]
Using argv[0] to determine behavior definitely used to be standard,
back in the pre-Linux days. mv and ln, I believe were the
Hi,
On Tue, Dec 04, 2012 at 03:25:05PM -0800, Kevin Dalley wrote:
and CMAKE_INSTALL_PREFIX.
cmake -DCMAKE_INSTALL_PREFIX=/home/kevin
make clean; make VERBOSE=1; make VERBOSE=1 install
ldd ~/bin/xfreerdp
linux-vdso.so.1 = (0x7fff887ff000)
libXinerama.so.1 =
Hi Kevin,
Ok, let's make take a decision right now: there will be backwards
compatibility for the old options as well. There is a bunch of ways I can
think of that would allow us to detect which set of options is used with
very high accuracy. This settles the matter which a lot of you are
Actually, cmake does support having CMAKE_INSTALL_PREFIX to be used so
that the installed executable search the location where the libraries are
installed.
You can see examples similar to this in the section
Always full RPATH
of this document.
http://www.vtk.org/Wiki/CMake_RPATH_handling
The fact that some of the discussion happens on IRC is partially behind
this. I've discussed this a lot on IRC but not on the mailing list. I
usually get a lot more advice on IRC than on the mailing list, and what came
out of the discussions I had with other community members is that while
12 matches
Mail list logo
