* Return pointer to message rather than message; cleaned up API surface to remove uAMQP details
* ASAN configuration via CMAKE preset, not environment variable
* clang-tidy fixes
# This pull request moves the core AMQP functionality to main. It is still very much a work in progress, but moving it to main will reduce the complexity associated with working in feature branches.
---------
Co-authored-by: Azure SDK Bot <53356347+azure-sdk@users.noreply.github.com>
Co-authored-by: Konrad Jamrozik <kojamroz@microsoft.com>
Co-authored-by: Victor Vazquez <victor.vazquez@microsoft.com>
Co-authored-by: Daniel Jurek <djurek@microsoft.com>
Co-authored-by: Ben Broderick Phillips <bebroder@microsoft.com>
Co-authored-by: George Arama <50641385+gearama@users.noreply.github.com>
Co-authored-by: Rick Winter <rick.winter@microsoft.com>
Co-authored-by: Ahson Khan <ahkha@microsoft.com>
* Start of tracing prototype
* Created initial implementation of azure-core-opentelemetry package
* New version of enabling MSVCRT Lib for static configs
* Attempt to add OpenTelemetry tests to build
* Take a dependency on OpenTelemetry version 1.3
* Added service API level tracing support
* API Review feedback
It all started with UWP. The [docs](https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps?view=msvc-170) say: "`Environment variables are not available to UWP apps.`". And it truly won't work, I tried: linker error, the function is simply not present.
So, for a year or so, we were `ifdef`ing everything enivoronment-related: console logger, environment credential, managed identity credential.
And then just recently we wanted to enable our CI for UWP, including tests and samples. And it required to do more ifdefs (in vcpkg, we don't build samples or tests, so that problem did not exist).
It just became more messy. Especially in samples - you can see how we would disable warning with `#pragma warning(disable : 4996)` or defining `_CRT_SECURE_NO_WARNINGS` already, but now came UWP, so we would have to add comment that `getenv()` is not available and make the sample compilation to either fail with clear message, or throw an exception. Plus we would have to detect that we are being compiled on UWP, which also adds visual clutter for reader. You can see how such an irrelevant (for a sample) thing as `getenv` was consuming more and more lines of sample code and reader's attention.
But then! I read docs on more APIs for UWP. And I noticed that on .NET you can read environment variables. So I went and checked Win32 API docs for [GetEnvironmentVariable()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getenvironmentvariable) - it says: "`Minimum supported client: ... UWP apps`".
**GetEnvironmentVariable() works on UWP!**
And so does `SetEnvironmentVariable()` (our tests use it, which means we can make all of them work and execute for UWP).
That's good news, but now it would probably be more code: it usually takes more lines to invoke WinAPI, it is no more an one-liner to call `getenv()/setenv()`. So, I encapsulated that into `Azure::Core::_internal::Environment::GetVariable()` and `SetVariable()`. You can see how much less ifdefs is in our code now. Not to mention it works on UWP!
Per team request, that API is SDK-internal. Samples use their own mini-helper project, `get-env-helper` that makes is so that `getenv()` works naturally on Linux and macOS, compiles without warnings and works on Win32, and compiles and works on UWP (using `GetEnvironmentStringsA()`)
If it was for me, I would just make `Azure::Core::Environment::GetVariable()` public and simplify even further, I think it would be beneficial for sample readers (you can see that extra `get-env-helper` stuff adds just a little more visual clutter, compared to nothing). But I can see reasons against that, why team did not want to do it.
* Generate map files in build
* Add .map file artifact publishing
* Add Xlinker to spelling exceptions
* Remove PublishMapFiles from clang builds
* Generate the map file artifact name
* CXX_COMPILER_ID and some logging for Clang which might be linking using the GNU linker by default
* More logging
* Move logging out of conditional
* Logging up high, use OS to determine which link flags to set
* Use linker options specific to AppleClang's context, publish map files for all platforms
Part of https://github.com/Azure/azure-sdk-for-cpp/issues/1277, checking what types of warnings the CI emits.
Verified all SDK product `.cpp`, `.hpp`, `.txt`, and `.md` files, primarily focused on azure-core. They are all clean now. There are some exceptions that needs to be added for keyvault and storage, but they are false positives, so not a concern.
> `cspell lint --config .vscode/cspell.json *.hpp */**/*.hpp`
CSpell: Files checked: 188, Issues found: 0 in 0 files
> `cspell lint --config .vscode/cspell.json *.cpp */**/*.cpp`
CSpell: Files checked: 186, Issues found: 88 in 15 files (keyvault and storage false positives, or tests)
> `cspell lint --config .vscode/cspell.json *.md */**/*.md`
CSpell: Files checked: 45, Issues found: 5 in 2 files (eng/common)
> `cspell lint --config .vscode/cspell.json *.txt */**/*.txt`
CSpell: Files checked: 44, Issues found: 0 in 0 files
> `cspell lint --config .vscode/cspell.json *.* */**/*`
CSpell: Files checked: 646, Issues found: 328 in 69 files (most of these are in eng\docs\api\assets\style.css or eng/common)
Deprioritize and ignored the errors from the test files (including test resource json files), and `eng/common` since those need to be centrally fixed.
* Get static/dynamic CRT link options in sync
* Update docs
* PR feedback
* en-us
* Another 'en-us' in a link
* MSVC_USE_STATIC_CRT
* Update README.md
Co-authored-by: Anton Kolesnyk <antkmsft@users.noreply.github.com>
Adding CMake module to enable/disable transport adapters
TRANSPORT ADAPTER BUILD
Default: If no option is explicitly added, curl will be used for POSIX and WIN HTTP for WIndows
Windows: Both CURL and WIN_HTTP can be build to be used.
POSIX: Only CURL is acceptable. If WIN_HTTP is set, generate step will fail for user
Defines `BUILD_WIN_HTTP_TRANSPORT_ADAPTER` and `BUILD_CURL_HTTP_TRANSPORT_ADAPTER` for source code
Fixes#350
* Add version.txt
* Add doc generation for template
* Add version.hpp parsing and update capabilities to cmake and engsys
* Get-SdkVersion -> Get-PkgVersion
* Move Update-PkgVersion.ps1 under eng/scripts
* Get-PackageVersion -> Get-PkgVersion
* Update paths, params, verbosity
* Couple fixes to output and make use of new SemVer version
* Add fallback support for verison.txt in cases where we still use it to unblock release artifact generation
* Use version information in release pipeline
* Add workaround to generate storage pipeline artifacts
* eng/scripts/
* Write warning
* Haven't released storage-file-shares yet according to releases on GitHub
* Set release date on changelog.md
* Update CHANGELOG.md to indicate this is a test release
* Remove fallback exception for storage
* Re-add Rick's suggestions
* Revert "Remove fallback exception for storage"
* Add ci.yml for storage
* OSVmImage
* Use correct name for storage
* Update ci.ymls
* Documentation generation
* Fix tabbing
* More tabbing
* Use correct service directory for storage ci.yml
* Add docs assets
* Use cpp for dropdown generation
* Use cmake to generate documentation
* Use CMake to generate doxygen docs
* BuildArgs -> GenerateArgs
* Correct template path
* More CURL options
* Install curl to satisfy minimum build requirements
* use dependency variable name
* Add VCPKG_DEFAULT_TRIPLET
* Always generate documentaion when -DBUILD_DOCUMENTATION=YES
* Build docs at top level
* Change variable names, simplify cmake-build.yml
* -DBUILD_DOCUMENTATION
* Try using MathJax for formula rendering instead of Latex
* Add version.txt for storage
* artifact.Name -> artifact.Path
* Build docs by target
* Remove Doxyfile
* Remove Doxyfile.template
* Remove generate_docs.py, we are using cmake
* Pass CtestRegex to archetype-sdk-client job template)
