On Wed, Feb 1, 2012 at 1:29 AM, Stephan Bergmann <sbergman@redhat.com> wrote:
On 02/01/2012 05:14 AM, Norbert Thiebaud wrote:
Looking at gbuildifying idlc, I noticed the glibc hack to get a getopt
implementation on platform that don't have a native one.
so, I wrote a gnu-compatile implementation based on
http://www.kernel.org/doc/man-pages/online/pages/man3/getopt.3.html
and I intend to add it to osl for platform that do not define
HAVE_GETOPT="YES" in configure.in
[...]
If you feel strongly against that, please let me know.
I'm not too excited, given that our code base is already too large, anyway,
and adding something to sal has higher maintenance implications than adding
it outside the URE interface.
I can add in somewhere else... is sounded like sal was a natural... on
the other hand it could be re-used in a couple of soltools executable
so, maybe I could put it there, as a static lib
Note that getopt is used in idlc and rscdep and partially
re-implemented in soltools/cpp and soltools/javadep
So, if there is a reasonably cheap alternative (like Boost's Program
Options), I wouldn't mind if we used that instead.
getopt is used in C-programs. what I did was a drop-in 'replacement'
(that compile to nothing on platform that have a native one). cramming
C++ and boost into these does not seems to help for 'our code base is
already large' or 'high maintenance' at least for me.
Norbert
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.