qtgrpc/src/tools/qtprotoccommon/options.h

67 lines
1.9 KiB
C
Raw Normal View History

// Copyright (C) 2022 The Qt Company Ltd.
// Copyright (C) 2019 Alexey Edelev <semlanik@gmail.com>
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
#ifndef GENERATOROPTIONS_H
#define GENERATOROPTIONS_H
#include <string>
namespace qtprotoccommon {
/*!
\ingroup generator
\private
\brief The GeneratorOptions class
*/
class Options
{
Options();
static Options &mutableInstance();
public:
enum class HeaderGuardType {
Pragma,
ProtoFilename,
};
enum GeneratorType {
QtProtobufGen = 0,
QtGrpcGen
};
~Options();
Options(const Options &) = delete;
Options &operator=(const Options &) = delete;
Options(Options &&) = delete;
Options &operator=(Options &&) = delete;
static const Options &instance();
static void setFromString(const std::string &options, GeneratorType type, std::string *error);
bool hasQml() const { return m_qml; }
bool generateComments() const { return m_generateComments; }
bool isFolder() const { return m_isFolder; }
bool generateFieldEnum() const { return m_generateFieldEnum; }
const std::string &extraNamespace() const { return m_extraNamespace; }
const std::string &exportMacro() const { return m_exportMacro; }
Fix the generation of the export macro Consider the EXPORT_MACRO CMake argument of qt_add_<protobuf|grpc> calls. Add the support for the EXPORT_MACRO option extras to the qt<protobuf|grpc>gen generators. The extras now allow setting: - export file name - boolean flag that indicates if export file needs to be generated The EXPORT_MACRO option of the generators now has the following format: EXPORT_MACRO=<export_name>[:export_filename[:<true|false>]] If export_filename is not set, then generators fall back to the previos behavior and use the export_name as the export filename base, the file will be generated unconditionally. If export_filename is set and the follow boolean flag is not set or is set to false, generators skip the generating of the export file. [ChangeLog][Protobuf][qtprotobufgen] EXPORT_MACRO option now has the following format: EXPORT_MACRO=<export_name>[:export_filename[:<true|false>]] New option extras allow setting the generated export filename and control if it should be generated at the generator run. [ChangeLog][GRPC][qtgrpcgen] EXPORT_MACRO option now has the following format: EXPORT_MACRO=<export_name>[:export_filename[:<true|false>]] New option extras allow setting the generated export filename and control if it should be generated at the generator run. Pick-to: 6.7 Fixes: QTBUG-121854 Change-Id: Ifff6506ab363d18dc417f222e9929d7eba135d8a Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-02-03 10:25:33 +00:00
const std::string &exportMacroFilename() const { return m_exportMacroFilename; }
bool generateMacroExportFile() const { return m_generateMacroExportFile; }
HeaderGuardType headerGuard() const { return m_headerGuard; }
Long live mutable getters The functionality is desirable by some users, we re-enable it. New API addresses the core issue that is partially related to QTBUG-119912, but has wider concequences in blind use in user projects. We add the 'mut' prefix to all mutable getters to make the mutable access explicit. Overload approach leads to unwanted detaches not only whe is used be moc-generated code, but also in user projects if developers do not pay enough attention to const modifiers of their variables/references. We declined to restore it, dispite it was the better looking API, in favor to the code safety. This also reveals the code clashing scenario, when the overload might happen if the message has both 'a' and 'mutA' fields in its definition. This scenario is kindly forbidden by our generator, and sanitized at very early stages. We expect that it won't happen in user projects, but even if it will, the solution is to rename the field when generating Qt code. The serialization/deserialization do not depend on field naming directly. json_name attribute also will help to workaround this. The undocumented ALLOW_MUTABLE_GETTER_CONFLICTS option allows clashing the mutable getter names, but its usage currently limited by our internal code only. The reason unfixed QTBUG-119912 issue in moc. Once the issue is fixed, the moc version check should get the proper version, but not '99' as for now and the ALLOW_MUTABLE_GETTER_CONFLICTS will become public. Another design solution is the use of overloaded functions that return pointers, like it's done it the reference protobuf. But this kind of API leaves the pointer ownership undefined and decided to not be used. [ChangeLog][Protobuf] The generated messages now have the mutable getters for the fiels of the message type. The getters have 'mut' prefix and implicily allocate the respective fields if needed, so the use of intermediate message objects is not required. Task-number: QTBUG-119913 Change-Id: I09b9ee37e1fbbe37b9c3cb501e92442da8ad3e4b Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
2025-03-14 11:40:54 +00:00
bool mutableGetterConflicts() const { return m_mutableGetterConflicts; }
private:
bool m_generateComments;
bool m_isFolder;
bool m_generateFieldEnum;
std::string m_extraNamespace;
std::string m_exportMacro;
Fix the generation of the export macro Consider the EXPORT_MACRO CMake argument of qt_add_<protobuf|grpc> calls. Add the support for the EXPORT_MACRO option extras to the qt<protobuf|grpc>gen generators. The extras now allow setting: - export file name - boolean flag that indicates if export file needs to be generated The EXPORT_MACRO option of the generators now has the following format: EXPORT_MACRO=<export_name>[:export_filename[:<true|false>]] If export_filename is not set, then generators fall back to the previos behavior and use the export_name as the export filename base, the file will be generated unconditionally. If export_filename is set and the follow boolean flag is not set or is set to false, generators skip the generating of the export file. [ChangeLog][Protobuf][qtprotobufgen] EXPORT_MACRO option now has the following format: EXPORT_MACRO=<export_name>[:export_filename[:<true|false>]] New option extras allow setting the generated export filename and control if it should be generated at the generator run. [ChangeLog][GRPC][qtgrpcgen] EXPORT_MACRO option now has the following format: EXPORT_MACRO=<export_name>[:export_filename[:<true|false>]] New option extras allow setting the generated export filename and control if it should be generated at the generator run. Pick-to: 6.7 Fixes: QTBUG-121854 Change-Id: Ifff6506ab363d18dc417f222e9929d7eba135d8a Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-02-03 10:25:33 +00:00
std::string m_exportMacroFilename;
bool m_generateMacroExportFile;
bool m_qml;
Long live mutable getters The functionality is desirable by some users, we re-enable it. New API addresses the core issue that is partially related to QTBUG-119912, but has wider concequences in blind use in user projects. We add the 'mut' prefix to all mutable getters to make the mutable access explicit. Overload approach leads to unwanted detaches not only whe is used be moc-generated code, but also in user projects if developers do not pay enough attention to const modifiers of their variables/references. We declined to restore it, dispite it was the better looking API, in favor to the code safety. This also reveals the code clashing scenario, when the overload might happen if the message has both 'a' and 'mutA' fields in its definition. This scenario is kindly forbidden by our generator, and sanitized at very early stages. We expect that it won't happen in user projects, but even if it will, the solution is to rename the field when generating Qt code. The serialization/deserialization do not depend on field naming directly. json_name attribute also will help to workaround this. The undocumented ALLOW_MUTABLE_GETTER_CONFLICTS option allows clashing the mutable getter names, but its usage currently limited by our internal code only. The reason unfixed QTBUG-119912 issue in moc. Once the issue is fixed, the moc version check should get the proper version, but not '99' as for now and the ALLOW_MUTABLE_GETTER_CONFLICTS will become public. Another design solution is the use of overloaded functions that return pointers, like it's done it the reference protobuf. But this kind of API leaves the pointer ownership undefined and decided to not be used. [ChangeLog][Protobuf] The generated messages now have the mutable getters for the fiels of the message type. The getters have 'mut' prefix and implicily allocate the respective fields if needed, so the use of intermediate message objects is not required. Task-number: QTBUG-119913 Change-Id: I09b9ee37e1fbbe37b9c3cb501e92442da8ad3e4b Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
2025-03-14 11:40:54 +00:00
bool m_mutableGetterConflicts;
HeaderGuardType m_headerGuard = Options::HeaderGuardType::ProtoFilename;
};
}
#endif // GENERATOROPTIONS_H