Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MINIFICPP-2346-P1: Integrated Conan2 for OpenSSL, CURL, ZLIB & Build MiNiFi #1793

Open
wants to merge 26 commits into
base: main
Choose a base branch
from

Conversation

james94
Copy link
Contributor

@james94 james94 commented May 21, 2024

Result Update (Oct 3, 2024): After addressing @szaszm , @lordgamez and @martinzink feedback. I verified that when I build MiNiFi with conan build, 218 CTESTs pass out of 219. Similarly, when I build MiNiFi with standalone CMake, then I run CTESTs, 218 out of 219 pass too. Similarly, when I create a MiNiFi conan package and then run CTESTs, 218 out of 219 pass. For now, ControllerTests fail since libarchive is disabled.

  • Also I was able to revert the RocksDB patches (arm7.patch, dboptions_equality_operator.patch, cstdint.patch) back to how they were in MiNiFi main branch. With conan fuzzy patching, I could then create a custom RocksDB conan package even with patch code vs actual source code having some slight differences. RocksDB custom conan package is separate from standalone CMake's BundledRocksDB. So, when a user wants to build MiNiFi using conan build, MiNiFi will use the custom RocksDB conan package. When a user wants to build MiNiFi using standalone CMake, MiNiFi will use BundledRocksDB. Theres a GetRocksDB.cmake to help with choosing conan or standalone CMake RocksDB.

Result Update (Oct 2, 2024): Created RocksDB Conan Recipe to take patches like BundledRocksDB. Also when we create the RocksDB conan package, it not only builds with the patches like BundledRocksDB, it also incorporates ZLib and ZStd conan packages too. Therefore, now that we use a conan RocksDB for building MiNiFi with conan, when we build MiNiFi with standalone CMake, we use the original version of BundledRocksDB that was in 'main' branch before I modified it. I verified that when I build MiNiFi with conan, 218 CTESTs pass out of 219. Similarly, when I build MiNiFi with standalone CMake, then I run CTESTs, 218 out of 219 pass too.

Result Update (Aug 15, 2024): For the conan build and conan create approaches for MiNiFi C++, 217/219 TESTs PASS. For standalone CMake approach, 275/275 TESTs PASS. For the conan approach, we see 219 TESTs were run since I DISABLED some of the MiNiFi features (Libarchive, AWS, SQL, GCP, Lua). Also a heads up, I already have most of these MiNiFi settings ENABLED using the conan approach in my original MiNiFi PR-1775, but I wanted to keep this PR-1793 small, so left them DISABLED, so its easier to create the MiNiFi conan package. For the standalone CMake approach, we see all 275 TESTs were run since I went with the default settings when building MiNiFi.

Verified I can Install & Build MiNiFi w OpenSSL, CURL, ZLIB using conan, then I set the MINIFI_HOME environment variable & ran minifi binary executable.

Will add the steps to reproduce (later we can integrate conan into the python bootstrap, the goal was to introduce you guys to the conan build approach with minimal changes): @lordgamez @szaszm

# make sure to install conan2 for your environment
sudo pip install --force-reinstall -v "conan==2.0.17"

# create a "default" conan profile, so conan has it on record, before using your own custom profile. Gets created in ~/.conan2/
conan profile detect

# conanfile.py is in root dir of MiNiFi C++ project
cd $HOME/nifi-minifi-cpp

# create MINIFI_HOME env variable for binary executable minifi
export MINIFI_HOME=$(pwd)

# In case you need to delete all conan packages
# conan remove "*" -c

# Create custom RocksDB conan package with MiNiFi's patches applied
pushd thirdparty/rocksdb/all

conan create . --user=minifi --channel=develop --version=8.10.2 -pr=../../../etc/conan/profiles/release-linux

popd # Exit thirdparty/rocksdb/all

# install conan packages for MiNiFi C++ using conanfile.py invoking Conan
# since we created default profile earlier, we can override it with our own minifi profile
# make sure path is correct; Our conanfile.py also includes our custom RocksDB conan package
conan install . --build=missing --output-folder=build_conan -pr=$HOME/nifi-minifi-cpp/etc/conan/profiles/release-linux

# build MiNiFi C++ using conanfile.py invoking Conan & CMake
conan build . --output-folder=build_conan -pr=$HOME/nifi-minifi-cpp/etc/conan/profiles/release-linux

# verify we can run minifi binary executable
./build_conan/bin/minifi

Similar to make package that we would run using standalone CMake, with conan, we can create a MiNiFi C++ conan package, which allows us to more easily integrate MiNiFi C++ library and its assets into other C++ projects. Here is the command to create the MiNiFi C++ conan package:

cd $HOME/nifi-minifi-cpp

conan create . --user=minifi --channel=develop -pr=$HOME/nifi-minifi-cpp/etc/conan/profiles/release-linux

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

For all changes:

  • Is there a JIRA ticket associated with this PR? Is it referenced
    in the commit message?

  • Does your PR title start with MINIFICPP-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

  • Has your PR been rebased against the latest commit within the target branch (typically main)?

  • Is your initial contribution a single, squashed commit?

For code changes:

  • If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
  • If applicable, have you updated the LICENSE file?
  • If applicable, have you updated the NOTICE file?

For documentation related changes:

  • Have you ensured that format looks appropriate for the output in which it is rendered?

Note:

Please ensure that once the PR is submitted, you check GitHub Actions CI results for build issues and submit an update to your PR as soon as possible.

@james94 james94 changed the title Integrated Conan2 for OpenSSL, CURL, ZLIB & Build MiNiFi MINIFICPP-2346-P1: Integrated Conan2 for OpenSSL, CURL, ZLIB & Build MiNiFi May 21, 2024
cmake/MiNiFiOptions.cmake Outdated Show resolved Hide resolved
cmake/BundledZLIB.cmake Outdated Show resolved Hide resolved
@szaszm
Copy link
Member

szaszm commented May 21, 2024

The macOS CI failure will be fixed in #1790, and the Docker integration test failure in #1795. The clang job fails because of a linter issue in the conanfile.

@james94
Copy link
Contributor Author

james94 commented May 22, 2024

@szaszm If I get access to a macOS, I can looking into fixing the linter issue in the conanfile. Currently, I am testing MiNiFi from Ubuntu 22.04. I can later test it in Windows too if needed. For now, I addressed @martinzink suggested updates for integrating conan into MiNiFi build infrastructure.

@james94 james94 requested a review from martinzink May 22, 2024 07:19
@szaszm
Copy link
Member

szaszm commented May 22, 2024

@james94 You don't need a macOS to fix the python linter issue, it's not OS-specific. Just run this from a build directory:

cmake --build . --target flake8

And make sure flake8 is installed.

This is the output:

[1/2] cd /home/szaszm/nifi-minifi-cpp-3/build-clang-ninja && /home/szaszm/nifi-minifi-cpp-3/run_flake8.sh /home/szaszm/nifi-minifi-cpp-3
FAILED: CMakeFiles/flake8 /home/szaszm/nifi-minifi-cpp-3/build-clang-ninja/CMakeFiles/flake8 
cd /home/szaszm/nifi-minifi-cpp-3/build-clang-ninja && /home/szaszm/nifi-minifi-cpp-3/run_flake8.sh /home/szaszm/nifi-minifi-cpp-3
/home/szaszm/nifi-minifi-cpp-3/conanfile.py:2:1: F401 'conan.tools.env.VirtualRunEnv' imported but unused
/home/szaszm/nifi-minifi-cpp-3/conanfile.py:9:1: E302 expected 2 blank lines, found 1
/home/szaszm/nifi-minifi-cpp-3/conanfile.py:18:53: E231 missing whitespace after ','
ninja: build stopped: subcommand failed.

@szaszm
Copy link
Member

szaszm commented May 22, 2024

I'm having trouble with conan, due to a missing profile. It seems like installation alone is not enough.

@james94
Copy link
Contributor Author

james94 commented May 22, 2024

@szaszm yeah I was hoping that the conan installation would have automatically created a default conan profile. First lets create a default profile for conan first (then later we'll override it with our minifi conan profile):

# create a "default" conan profile, so conan has it on record, before using your own custom profile. Gets created in ~/.conan2/
conan profile detect

Once you have the default conan profile, then you can try overriding it again with our minifi conan profile:

# install conan packages for MiNiFi C++ using conanfile.py invoking Conan
# since we created default profile earlier, we can override it with our own minifi profile
# make sure path is correct
conan install . --build=missing --output-folder=build_conan -pr=$HOME/nifi-minifi-cpp/etc/build/conan/profiles/release-linux

NOTE: The nice thing about docker environment is we would have already created the default conan profile at the beginning and then later used our specific minifi conan profile.

Does the extra conan profile detect command help?

@szaszm
Copy link
Member

szaszm commented May 22, 2024

@james94 what docker environment do you mean? I was trying on arch linux, no containers.

@james94
Copy link
Contributor Author

james94 commented May 22, 2024

@szaszm I meant we could leverage a docker environment like the one that is mentioned in the README and extend it with conan2 support: https://github.com/apache/nifi-minifi-cpp?tab=readme-ov-file#building-a-docker-image

I usually just launch my own docker container with needed build dependencies for MiNiFi C++, so I can build it within my docker container.

You could also try it directly on linux too.

@james94
Copy link
Contributor Author

james94 commented May 31, 2024

@szaszm @martinzink @lordgamez just checking in, anything I can do to help speed up testing toward this PR?

Copy link
Member

@martinzink martinzink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late reply, I was on holiday.
It would be nice if the minifi options were configurable through the conan options so we could set the extensions without editing conanfile.py, but overall I like the direction (and that could be implemented in followup PRs) 👍

@james94
Copy link
Contributor Author

james94 commented Jun 3, 2024

Yes I agree with you @martinzink
I do plan to add being able to configure minifi options mapping to conan options through the bootstrap py script, but that will be in a later PR, so we keep this initial PR light as @szaszm suggested.

cmake/MiNiFiOptions.cmake Outdated Show resolved Hide resolved
conanfile.py Show resolved Hide resolved
@szaszm
Copy link
Member

szaszm commented Jun 5, 2024

I ran the following commands:

conan profile detect
export MINIFI_HOME=$(pwd)  # I was in the source tree root
conan install . --build=missing --output-folder=build_conan
conan build . --output-folder=build_conan

conan install ran suspiciously quickly, I don't think it had to build anything from source, but it did install zlib/1.3.1, openssl/3.2.1 and libcurl/8.6.0.

Unfortunately OpenSSL and Zlib were still built from source using ExternalProject during the CMake build. I think when calling CMake through Conan, they should be using the Conan packages.

CMakeLists.txt Show resolved Hide resolved
@james94
Copy link
Contributor Author

james94 commented Jun 9, 2024

@szaszm @martinzink with respect to commit "49de56c": I verified I can build MiNiFi C++ using conan with the specific conan profile etc/conan/profiles/release-linux and with the sources for MINIFI_LIBCURL_SOURCE, MINIFI_OPENSSL_SOURCE
and MINIFI_ZLIB_SOURCE all set to CONAN successfully. There were 2 ENABLED options that I needed to set to OFF, which were ENABLE_LIBARCHIVE and ENABLE_AWS since the build would fail, but later I can get those working again since on my bigger PR-1775 "#1775", I was able to keep those options ENABLED when building MiNiFi C++ with conan. I used the following command to build MiNiFi C++ with conan:

conan build . --build=missing --output-folder=build_conan -pr=etc/conan/profiles/release-linux

I did double check I can still build MiNiFi C++ using standalone CMake approach with all the default ENABLED options set to their original values as specified in MiNiFiOptions.cmake too. I used these commands to build MiNiFi C++ with cmake:

mkdir build_cmake
cd build_cmake

cmake ..
make -j $(nproc)

Please try the conan build MiNiFi C++ approach again when you get a chance

@lordgamez
Copy link
Contributor

@james94 I checked and it seems to build successfully for me. Could you please rebase the PR to the latest main brach to be able to run the CI on it?

@james94
Copy link
Contributor Author

james94 commented Jun 10, 2024

@lordgamez thanks for verifying you can build MiNiFi C++ with conan on your side. I appreciate it. I will rebase on latest MiNiFi main branch.

@james94
Copy link
Contributor Author

james94 commented Jun 17, 2024

@lordgamez @szaszm I merged latest upstream main branch into my forked main branch and then merged my forked main branch into my MINIFICPP-2346-P1 branch.

  • Also I chose not to rebase and instead went for the merge approach since rebasing in the passed caused me to lose my updates on previous branches.

After merging upstream main, I verified I can build MiNiFi using conan and then standalone CMake.

@james94 james94 changed the base branch from MINIFICPP-2251 to main June 17, 2024 16:32
@lordgamez
Copy link
Contributor

Hi @james94, thanks for the update! Unfortunately the lua.org page where we retrieved the lua sources went down, that's the reason the CI jobs are failing. We merged a commit to move from lua.org to the github page to retrieve the source files with the following commit: b0b2cf6 Could you rebase it again to be able to run the CI correctly?

@szaszm
Copy link
Member

szaszm commented Jun 19, 2024

@james94 I could rebase your branch easily without data loss. The existing merge complicates things a bit, but not too much. Here's what I did:

git checkout main
git pull upstream main  # update local main branch from apache/nifi-minifi-cpp
git checkout MINIFICPP-2346-P1
git reset --hard HEAD~1  # remove merge commit from the top
git rebase -i main  # interactive rebase
# then edited the file, removing Gabor's commits, which were the first 6 IIRC, like here on the "commits" tab. "Making OpenSSL and curl mandatory", + 5x "review update" commits. At the end, exited the editor and git did the rebase.
# at the end, there is a successful rebase to the latest main, with no conflicts, and only your commits.

Thanks for sharing the conan profile at etc/conan/profiles/release-linux. I have concerns about the hardcoded compiler version and "system package manager" settings, but I don't know if this causes any real issues.

Tried compiling on a half-upgraded Ubuntu 22.04 to 24.04, the system packages should already be the 24.04 versions. I'll try again later with another system. I encountered these issues:

CMake Error at <line in CMakeLists.txt> (target_link_libraries):                                                                                                                                                                                                      
  Target "<target>" links to:                                                                                                                                                                                                                                     
                                                                                                                                                                                                                                                                 
    zstd::zstd                                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                                 
  but the target was not found.  Possible reasons include:                                                                                                                                                                                                       
                                                                                                                                                                                                                                                                 
    * There is a typo in the target name.                                                                                                                                                                                                                        
    * A find_package call is missing for an IMPORTED target.                                                                                                                                                                                                     
    * An ALIAS target is missing.                                                                                                                                                                                                                                

Affected targets are rocksdb, db_bench, db_sanity_test, write_stress, db_repl_stress, rocksdb_dump, rocksdb_undump, db_stress. It looks like all of them are RocksDB-related.

Also, I would appreciate if you could add the necessary changes to keep the AWS and libarchive extensions enabled and working, so that we can eventually merge this PR standalone without breaking important functionality.

@james94
Copy link
Contributor Author

james94 commented Jun 24, 2024

Thanks @szaszm for the steps to run a git rebase without causing data loss. I will give it a try. I think the reason we are seeing the zstd::zstd target not found issue is because we move from Ubuntu 22.04 to Ubuntu 24.04 and maybe conancenter doesn't provide the prebuilt conan package out of box. I think we just need to run these two conan commands:

conan install . --build=missing --output-folder=build_conan
conan build . --output-folder=build_conan

I will look into it today after work. I will follow your rebase steps for Ubuntu 22.04. Thanks again for sharing your steps. Later I will try Ubuntu 24.04. I believe there shouldn't be much of a difference.

@james94
Copy link
Contributor Author

james94 commented Jun 25, 2024

@szaszm @lordgamez for this latest git push, I followed marton's steps to do an interactive rebase and also removed the top merge commit that I had to clean up the history and leave only my commits for the git history. Now PR-1793's branch MINIFICPP-2346-P1 should be on top of the latest MiNiFi main branch. I also verified I could build MiNiFi using conan with conan's cmake wrapper and then I followed up by verifying I could still build MiNiFi using standalone CMake. Also it looked like the TESTS were on there way to passing too. When you guys get a chance, please review.

conanfile.py Outdated Show resolved Hide resolved
cmake/MiNiFiOptions.cmake Show resolved Hide resolved
conanfile.py Show resolved Hide resolved
conanfile.py Show resolved Hide resolved
conanfile.py Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
CONAN.md Show resolved Hide resolved
cmake/GetBZip2.cmake Outdated Show resolved Hide resolved
cmake/GetCatch2.cmake Outdated Show resolved Hide resolved
cmake/GetCivetWeb.cmake Outdated Show resolved Hide resolved
cmake/GetSpdlog.cmake Outdated Show resolved Hide resolved
thirdparty/rocksdb/all/patches/arm7.patch Outdated Show resolved Hide resolved
thirdparty/rocksdb/all/patches/cstdint.patch Outdated Show resolved Hide resolved
thirdparty/rocksdb/config.yml Outdated Show resolved Hide resolved
james94 and others added 26 commits October 9, 2024 00:37
Verified I can also build MiNiFi using standalone CMake still
Addressed martinzink's feedback adding GetLibCURL, GetOpenSSL and
GetZLIB cmake files that use prebuilt conan package when
MINIFI_USE_CONAN_PACKAGER is set, otherwise it uses bundled cmake
files from standalone cmake approach. After updating the files,
I verified I could build MiNIFi using conan build and then verified
I could build MiNiFi using standalone CMake approach. Furthermore,
I also verified I could run minifi binary
…ONAN_PACKAGER

tc variables can be used to change minifi options
After addressing some feedback and working with Marton on some build issues he was facing
with conan on his side, I realized that conan's OpenSSL, ZLib and LibCURL were being ignored
because I didn't update conanfile.py file's USE_CONAN_PACKAGER to be MINIFI_USE_CONAN_PACKAGER
to match with MiNiFiOptions.cmake one. Once I made that I update then when building MiNiFi C++,
it shows in the build output for OpenSSL, 'Using Conan Packager to manage installing prebuilt OpenSSL external lib'
and similar messages for zlib and libcurl. Thus, OpenSSL, ZLib and LibCURL arent build from source

since we use the conan prebuilt ones.

Also I verified that I can build MiNiFi C++ using default conan v2 profile using the similar steps
Marton tried. The main reason I suggested we use a particular conan profile in MiNiFi C++ is so each
environment where MiNiFi C++ is built has a consistent conan profile since each environment default generated
conan profile could be unique to that environment, which could cause issues in downloading prebuilt conan
packages.
…URCE vars

Was able to build MiNiFi C++ with the ENABLE_{External_Lib} variables set to OFF initially.
However, after a suggestion from Marton to leave the ENABLE external lib variables set to
their default values from MiNiFiOptions.cmake, I removed the tc.variables['ENABLE_{...}']
that overrode MiNiFiOptions.cmake ones and now am trying to build MiNiFi C++ using conan
where we use conan's OpenSSL, ZLib and LibCURL prebuilt conan packages alternative to building
them from source. I am debugging issues that come up from building MiNiFi using conan where
partly we use conan's prebuilt conan packages and then the remaining external libs are the ones
built from source. For instance, one finding related to needing to use the predefined conan profile
located in etc/conan/profiles/release-linux because of the gnu20 was required to build rocksdb
successfully. I found that for my environment, conan's generated default profile used gnu17,
which caused rocksdb to fail building, but setting conan to use gnu20 allowed it to succeed in
building rocksdb.
After I added new MiNiFi options for MINIFI_LIBCURL_SOURCE, MINIFI_OPENSSL_SOURCE
and MINIFI_ZLIB_SOURCE all set to CONAN, I tried building MiNiFi with all the default
ENABLED options, but there were two I needed to switch to OFF. I had to switch
ENABLE_LIBARCHIVE and ENABLE_AWS to OFF because they failed to build.

I do want to note that on my much larger PR where I built majority of MiNiFi
using conan to install most of the external libs, I was able to build MiNiFi
with openssl, libcurl, zlib and libarchive with no issues. I was also able to keep
AWS enabled.

I can do a follow PR where I bring back ENABLE_LIBARCHIVE and ENABLE_AWS to where
we can set them to ON and be able to successfully build MiNiFi using conan
Followed Marton's suggested steps to remove my merge commit, then do an interactive rebase to only include
my commits and remove Gabor's commits to keep a clean PR-1793 for my MINIFICPP-2346-P1 branch. For building
MiNiFi using conan with conan's cmake wrapper, I disabled building TESTS and disabled expression language
since they were causing compile issues. I believe I resolved them in my follow up PR-1813, which will only
be ready for further review once my PR-1793 is ready for merge and merged. After disabling these two components
of the build, I was able to build MiNiFi successfully. I verified I could still build MiNiFi using standalone cmake
and also verified I could still build it with TESTS enabled and expression language enabled and the other necessary
features that needed to be enabled to build MiNIFi with TESTS enabled. For the MiNiFi standalone cmake build,
I disabled features that werent needed like extra extensions for building faster.
Update cmake/MiNiFiOptions.cmake for add_multi_option with Comments portraying the Meaning of Each Option.

Co-authored-by: Márton Szász <[email protected]>
Thus, other people using Nix to install conan can now install conan 2.0.17 or
alternative supported version. I was able to build MiNiFi c++ using conan 2.0.17.
In process of testing creating the conan package too
…CONAN_PACKAGE

One of the concerns was that we wanted to make sure that README.md, LICENSE
, NOTICE and even the binary ones were included in the MiNiFi C++ conan package.

I removed the MINIFI_BUILD_CONAN_PACKAGE condition, so CPACK_PACKAGE_DESCRIPTION_FILE
and CPACK_RESOURCE_FILE_LICENSE are not ignored when creating the MiNiFi conan package.
This is for README.md and LICENSE.txt and NOTICE files including the binary ones.

As an alternative to using CPACK with CMake to make sure these files are included
in the MiNiFi conan package, through conanfile.py we assign our shared_sources variable
to export_sources and in our py file's package() method, we run cmake.install() to
ensure that the source files and binary files assets are copied into the MiNiFi conan package.

Also for the MiNiFi conan package, we copy over the .h, .i, .a and .so files into their
appropriate include/ folder and lib/ folder.
Verified after switching cmake include(...) conan package libs
to find_package(...) of that conan package lib name that I could
run conan build and conan create successfully
Verified can still create MiNiFi C++ conan package successfully
Verified can still create MiNiFi C++ conan package successfully. This OPENWSMAN tc.variable was related to the CMake
check that is now removed.
…22.04

Verified that I can build MiNiFi C++ in standalone CMake mode and that all 275 CTESTs PASS.
Verified I can run conan to build MiNIFi C++ with some features DISABLED, so its easier to
create the MiNiFi C++ conan package. In the case of building MiNiFi C++ with conan, when
we run CTEST, 219 TESTs run and 217 TESTs PASS. We dont include in conanfile.py 'cmake.ctest()',
so that we can manually run ctest after conan finishes building MiNiFi C++.

Also removed the test_package/ folder and C++ MiNiFi C++ test for AbstractProcessorTest since I
plan to later do a follow up PR that runs a new TEST that will be closer to how I plan
to use MiNiFi C++ in other C++ projects. For example, in one of the follow up PRs, I plan
to programmatically create an edge data pipeline that processes medical images as an example.

I think these updates will enable the CI/CD to pass, but also need to double check
The Build MiNiFi & Create MiNiFi Conan Package section in the README points to a CONAN.md
file that goes step by step on using the conan commands to compile MiNiFi and create
a MiNiFi conan package.
For conan, we install fmt 10.2.1 prebuilt conan package to not conflict with spdlog 1.14.0 prebuilt conan package.
However, when we switched to a newer version of fmt, that caused the LoggerTest to fail, which didn't happen
when we were using fmt 10.1.0 that was version installed when we used the standalone CMake approach. So, we updated
our TEST_CASE for 'fmt formatting works with the logger' to explicity create the chrono minutes duration,
followed by fmt format and then we pass our formatted minutes duration to our logger->log_critical, so we get
the expected fmt formatting to be '1m'. We didn't have to do this explicitly when we used fmt 10.1.0 since even
if we passed our logger->log_critical '1min', it would auto format to '1m'. For fmt 10.2.1 to have backward compatibility
with fmt 10.1.0 and the result we expected from this TEST_CASE in LoggerTests, we made this update.

I checked that when I build MiNiFi using conan and then build MiNiFi using standalone CMake, their LoggerTest PASSES.
Now when we build MiNiFi using conan and run ctests, we shouldn't see that zlib missing headers issue
…ld BundledRocksDB

 On a fresh dev Ubuntu 22.04 docker environment that mainly comes with the apt packages needed
to build MiNiFi, I realized that there were problems with compilation coming from BundledRocksDB,

so once I updated the BundledRocksDB to temporarily account for conan packages zstd & zlib,

  BundledRocksDB built rocksdb system library. When building MiNiFi with conan, I later plan
to switch from installing system library rocksdb to installing the conan package rocksdb with

 the needed patches. We were able to successfully install rocksdb sysem library when building

  MiNiFi with conan build and MiNiFi then built successfully using conan build.

    However, two ctests failed '34 - ProvenanceTests (Subprocess aborted)' and
'219 - ControllerTests (Failed)'.

  I didn't see the compilation failure for MiNiFi conan build related to

'librdkafka/kafka-external-prefix/src/kafka-external/src/rdcrc32.h:57:10' for

'fatal error: zlib.h: No such file or directory'.
Also when we create the RocksDB conan package, it not only builds with the patches like BundledRocksDB, it also
incorporates ZLib and ZStd conan packages too.

Therefore, now that we use a conan RocksDB for building MiNiFi with conan, when we build MiNiFi with standalone
CMake, we use the original version of BundledRocksDB that was in 'main' branch before I modified it.

I verified that when I build MiNiFi with conan, 218 CTESTs pass out of 219.
Similarly, when I build MiNiFi with standalone, then I run CTESTs, 218 out of 219 pass too.
…cise

Addressed Marton's feedback for conan linux profile to use ISO C++ & Then updated the Get<lib>.cmake
files messages related to conan to be more concise.

Rebuilt MiNiFi with conan and then standalone cmake. Also created MiNiFi conan package. In these 3
cases, I also checked the CTESTs to see that 218 out of 219 TEST CASES passed.
'219 - ControllerTests (Failed)' and thats expected for now since LIBARCHIVE is DISABLED.
Reverted rocksdb patches: cstdint.patch and doptions_equality_operator.patch by copying over
the ones from MiNiFi main branch.

Kept the brief update I made to arm7.patch since when I tried the original version
of arm7.patch from main branch, conan complained when trying to apply the patch.

Added the warning message in CONAN.md about conan integration with MiNiFi being experimental.

Updated the messages for GetLibXml2.cmake and GetSpdlog.cmake.

Verified I can build MiNiFi with standalone CMake, conan build and conan create
…package

After reverting RocksDB arm7.patch back to the one based on MiNiFi main branch, verified
I could still create custom RocksDB conan package using Fuzzy patching. Fuzzy patching
allows us to proceed creating a conan package like RocksDB where even if there is a minor
difference between patch code and actual source code, we can still apply the patch. This
fuzzy patching was key in us being able to successfully apply arm7.patch when creating
a custom RocksDB conan package. Previously we used apply_conandata_patches() when creating
the custom RocksDB conan package and it was too strict, so we'll stick with the fuzzy
patching approach.

Then I verified I could build MiNiFi using the conan build approach and then the standalone
CMake approach. Afterward, I verified I could create the MiNiFi conan package.

Finally, I double checked that 218 out of 219 CTEST cases passed for building MiNiFi
using conan build and then standalone CMake approaches. 218 out of 219 CTEST cases passed
after creating the MiNiFi conan package.
Verified I can build MiNiFi with conan build and standalone cmake.
Verified I can create MiNIFi conan package with conan create.
Copy link
Member

@szaszm szaszm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for your hard work and patience

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants