summaryrefslogtreecommitdiff
path: root/codemaker
AgeCommit message (Collapse)Author
2013-01-26gbuild: fix silly "expandtabs" in makefile VIM modelinesMichael Stahl
Change-Id: I54d8923ad315e8041fd3904da3a29f1a7a8c8b16
2013-01-26Remove redundant braces around for loopsStephan Bergmann
...that had once been workarounds for compilers that did not yet support the C++98 scoping rules for declarations in for-init-statements. Change-Id: I51dc42982b30bf3adea6de1a10a91c0b4b4acfbe
2012-12-18Replace chained O(U)StringBuffer::append() with operator+Christos Strubulis
Change-Id: I0fcd70cff092c7d90b57b9af9dcec99f23750f1c Signed-off-by: Luboš Luňák <l.lunak@suse.cz>
2012-12-03No reason to turn "throws nothing" specifications into commentsStephan Bergmann
...as had been done in 0295bd6b3f21dd648af6145ca23d90467f3cec73 "Remove exception spec from idl-generated c++ headers." Change-Id: I1b900a91be6db6cb4d7b60759e844117aa6b027d
2012-12-02cppumaker: do write exception specifications on --enable-dbgutilMichael Stahl
Exception specifications are useless for production code, but make for useful assertions in dbgutil builds (on platforms where they are enforced at runtime). Because we do not have API tests that exhaustively trigger all documented error conditions, much less the undocumented or wrongly handled error conditions that would cause the implementation to violate its API specification, there is likely some benefit in having these runtime-checked specifications in debug builds, in the hope that our various tests which may incidentally call various API methods, or general soffice usage, uncovers these bugs. Also, there may be some benefit to making API implementers more aware of the exception specifications, to quote Stephan's mail: To be able to programmatically react to an exception raised by a UNO method (which is the raison d'être of non-runtime UNO exceptions), the specification of that method must document the method's behavior with respect to raising that exception, and any implementation of the method must adhere to that specification. However, with that part of a UNO method's interface moved out of sight of a programmer writing a C++ implementation of that method, I fear that adherence to specification will degrade in practice. And that negatively affects an area where we do not shine anyway: reaction to errors. This partially reverts commits: 0295bd6b3f21dd648af6145ca23d90467f3cec73 155cd09b5eebe0c1eab0610a7f1f04f09de4b217 Change-Id: I9c7664c9f1b238f4f9501aacb065981236949440
2012-11-30c++ API: use css alias in generated headers, adds global css declThorsten Behrens
This changes all generated API headers (.hpp and .hdl) to use a namespace alias 'css' instead of the pointlessly long com::sun::star Makes the change in cppumaker & associated tools, adds a global namespace alias definition in sal/types.h, and removes a kiloton of local, now pointless-to-harmful versions of that alias from all over the code. Change-Id: Ice5a644a6b971a981f01dc0589d48f5add31cc0f
2012-11-29Prettify cppumaker output.Thorsten Behrens
Don't use extra-verbose RTL_CONSTASCII_USTRINGPARAM anymore. Write nicer nullary method prototypes. Change-Id: I1efdd6edd624c32852f47e5d2b266e90536b917b
2012-11-29Remove some commented-out or otherwise unused code.Thorsten Behrens
2012-11-29Remove exception spec from idl-generated c++ headers.Thorsten Behrens
The general agreement in the project is that c++ exception specs are pointless and add bloat in production code. See also this rant for more background: http://drdobbs.com/cpp/184401544 This removes the code that generates the exception specs on the generated c++ headers, and fixes up the few places that broke subsequently because of widening exception specs, which in turn was due to the rather unfortunate decision to not have a virtual dtor in XInterface. Change-Id: I60db26e1cc4d4fe6eeef5975e39497841e92588a
2012-11-28We only support MSVC 2008 (_MSC_VER 1500) or laterTor Lillqvist
We can drop or simplify many conditionals. Change-Id: I37e820e515cc09845c30b62c89ddb3b6ff370f97
2012-11-28OUString::replace() does not replace in-placeTor Lillqvist
Change-Id: I5a1d713ee8e9c913adad57b7d8fb0597f96a2db4
2012-11-23Remove some newly tagged unused methodsJulien Nabet
Change-Id: Ie55dfd19f223df62c091ffc4fdf28789b308a1c7
2012-11-23Adding SAL_DEPRECATED_INTERNAL to an implementation function is pointlessStephan Bergmann
...as there are typically no direct calls to it anyway. What is apparently needed is to decorate the cppumaker-generated headers instead: * cppumaker obtains deprecation-information from the documentation strings in .rdb files. As these are normally generated by idlc without documentation included (no -C), idlc got changed to nevertheless contain documentation consisting of just "@deprecated" in this case, to allow to easily tunnel this information to cppumaker always. * The mechanism of parsing for "@deprecated" in documentation strings is somewhat crude, of course. * For now, cppumaker only decorates C++ functions that correspond to UNOIDL interface attributes and methods. More should be possible (but, e.g., being able to decorate a complete C++ class corresponding to a deprecated UNOIDL interface type depends on whether all platforms would accept SAL_DEPRECATED_INTERNAL at the same position in a C++ class declaration. * This could also be extended to other languages than C++/cppumaker. * Always using SAL_DEPRECATED_INERNAL instead of SAL_DEPRECATED for decoration is to keep things simple and our codebase working. Improvements are possible here, too, of course. Change-Id: Ia2917892f780d477652e4cd9f286588a6898c3f5
2012-11-15dropped unused method: FileStream::openEnrico Weigelt, metux ITS
Change-Id: I3e6c1341666fddcfd1bd272a0943ca1de3e5d629 Reviewed-on: https://gerrit.libreoffice.org/1072 Reviewed-by: Tor Lillqvist <tml@iki.fi> Tested-by: Tor Lillqvist <tml@iki.fi>
2012-11-13fix system boostPeter Foley
Change-Id: Id80557cb47ab471a0f3a643a1c11a59e89c14c54
2012-11-13static libraries also require boost.Michael Meeks
2012-11-13cppumaker and javamaker also use boost.Michael Meeks
2012-11-12codemaker use boost, so declare the depNorbert Thiebaud
Change-Id: I64794acd804ed5059f54422d74bdd0ba1688cc91
2012-11-11codemaker_java needs boostPeter Foley
Change-Id: I64a6ae7bfed878d1fafda9125920340ec3eca378
2012-10-31add missing deps on sal headersDavid Tardon
Change-Id: I815ef8abaf4cd998e7b91fbadad56ddf0a7087ba
2012-10-26loplugin: unused aName string and whacky indentCaolán McNamara
Change-Id: I3febbc1618ca86f19c851a8eea313327a9c0a96c
2012-10-13loplugin: some log, indent and unused variable warningsCaolán McNamara
fix up some indents, remove some unused OUStrings and add some log areas Change-Id: I5c50807aff7a726b03b72522975d9b75e6685b9b
2012-10-11loplugin: more unused OUString and misleading indentationCaolán McNamara
Change-Id: Ic21ca9e14520f4f16c2d665a07a79ee1a46ab91d
2012-10-07Revert "For some reason saxparser aborts for me without this"Tor Lillqvist
Not needed now when we always generate comprehensive UDKAPI headers in the configuration where I thought the reverted change helped (it actually didn't). This reverts commit 73c3907bce33c07ef78c0bb9ff1e0df8b9fbb323. Change-Id: Iabbfec9b8e9d6963b31daa52dc574bed01d9eb4c
2012-10-06For some reason saxparser aborts for me without thisTor Lillqvist
This is in a Mac build tree using the 10.7 SDK and latest Xcode Clang. This codemaker-generated type stuff seems awfully fragile. Should we just bite the bullet and do the "comprehensive" thing for all UDKAPI types all the time on all platforms? Is that a sane question to ask? Change-Id: I9d17e76a83ff71898409179acb445832436f7bbd
2012-10-04sal_Bool->bool in codemakerNoel Grandin
Change-Id: Icea58e7c1dea14f524d6a8d479b7d85e79d6266b
2012-10-01Replace usage of rtl_*Memory with equivalent from string.hArnaud Versini
Change-Id: I50ffc10f007f03c3252ef0196b59b881429cc159 Reviewed-on: https://gerrit.libreoffice.org/734 Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com> Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
2012-10-01add missing deps on headers to static libsDavid Tardon
Change-Id: I7a28dfa13bf0f98a654eca98eb1cdfd99177f37a
2012-09-28Add css.reflection.XTypeDescriptionEnumerationAccess to the bootstrap typesTor Lillqvist
Needed for some unknown reason in a 64-bit Mac LO. Doesn't do any harm to have it included everywhere. Change-Id: I62ae599692bb922678caabe78b7e1c0588573bb2
2012-09-25replace remaining InterlockedCount() with inlined versionNorbert Thiebaud
Change-Id: Ifcfa48fc87f905a91470a5b0fd597b02f220784c Reviewed-on: https://gerrit.libreoffice.org/671 Tested-by: Norbert Thiebaud <nthiebaud@gmail.com> Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
2012-09-22use package instead of explicit include pathDavid Tardon
Change-Id: I11048d24b21549aa3ae79995a2c252c00e56d771
2012-09-22add missing dependencyDavid Tardon
Change-Id: Ibfe60fde8010755ee8c3ce1afce669400a44f6e2
2012-09-17Keep null service manager throw a DeploymentExceptionStephan Bergmann
...rather than a general RuntimeException, for consistency with existing service ctor code. Change-Id: Ia9ac14a1b5bcecb24394e7b9cade369f3f9303f0
2012-09-17Require XComponentContext.getServiceManager to throw instead of returning nullStephan Bergmann
This is such a fatal error that there is probably no point in trying to handle it, so allow to simplify client code by removing the requirement to check for a null return value. Simplified some client code accordingly (modules configmgr and ure, and the code generated by cppumaker and javamaker). Change-Id: I51c0b270ec73409374f7439a47ee061407a46e31
2012-08-30Add note about terminologyTor Lillqvist
Change-Id: Iecbd3d88e963222e9bf44412fc84245edb6659dc
2012-07-30udkapi, offapi: do not use #include "foo":Michael Stahl
Evidently on Windows, the newfangled ucpp handles #include "foo" differently from #include <foo> and treats it as a relative path, while the angle brackets always result in absolute paths. Since relative paths result in infinite rebuilds if make is invoked in a different directory, don't use #include "foo" in IDL files. Change-Id: Iedcda3a4be5542389a0be086f14541cda8dc5323
2012-06-12re-base on ALv2 code.Michael Meeks
2012-06-07XInterfaceTypeDescription missing from isBootstrapTypeStephan Bergmann
...it is base of XInterfaceTypeDescription2 (included in isBootstrapType), which ultimately caused uno-skeletonmaker to crash. Change-Id: I17421f58efd9edd4112532a3221125865cc5560e
2012-06-06removed dead codeTakeshi Abe
Change-Id: I02e535f0a0e55446e5a29297c2d05b1503805e71
2012-05-21codemaker: write version 49 (1.5) class filesMichael Stahl
The trick of writing generic types into class files of versions < 49 does no longer work with javac from OpenJDK 7: /comphelper/qa/complex/comphelper/Map.java:154: error: type Pair does not take parameters Pair< ?, ? >[] initialMappings = new Pair< ?, ? >[ _keys.length ]; There appears to be a related JDK bug for this, at some time javac had an undocumented option to produce similar class files that are also rejected now, this has been closed as "Not a Defect": http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078419 Change-Id: I8a504f6cbb3bb58cd914aebb88637cc6feb0bd48
2012-04-29make gbuild the default assumption of build.plBjoern Michaelsen
this removes dmake completely out of the build for migrated modules build.pl now assumes modules to be gbuild, unless there is a prj/dmake file Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
2012-04-20Don't build these command-line tools for non-desktop OSesTor Lillqvist
2012-04-14rename common* static libs to codemaker_* for clarity + dmake cleanupNorbert Thiebaud
2012-04-14gbuild conversion: codemaker moduleDavid Ostrovsky
2012-04-14replace APP?RPATH SDK by SDKBIN in old build systemDavid Tardon
Commit 0c80ad06fd96a4fec062a7edfff12bb65ef204b4 broke MacOS X builds because of this discrepancy. It would be easy to accept both, but I think it is better to be consistent with gbuild.
2012-04-06Replaced equalsAsciiL(RTL_CONSTASCII_STRINGPARAM(...)) with == operatorSzabolcs Dezsi
2012-03-29UNO BYTE is signedStephan Bergmann
This is hopefully a better fix for c589fa17b8f3e6ded0d1e04120781eb5d6735bc7 "Dalvik enforces byte constants being in range (-128..127)."
2012-03-28Dalvik enforces byte constants being in range (-128..127)Tor Lillqvist
2012-03-21idlc/README: correct nonsense added in 534b3a9b2eMichael Stahl
2012-03-14Enable -Wnon-virtual-dtor for GCC 4.6Stephan Bergmann
...which has the necessary features to support it. Change a lot of classes to either contain a protected non-virtual dtor (which is backwards compatible, so even works for cppumaker-generated UNO headers) or a public virtual one. cppuhelper/propertysetmixin.hxx still needs to disable the warning, as the relevant class has a non-virtual dtor but friends, which would still cause GCC to warn. Includes a patch for libcmis, intended to be upstreamed.
generated by cgit (git 2.34.1) at 2025-01-08 16:28:28 +0000