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

Link argument parsing functions from libraries, instead of duplicating their source files #1401

Conversation

dmikushin
Copy link
Contributor

This PR basically removes

-set(SHARED_SOURCES
-  ${SHARED_SOURCES}
-  ${LIB_SOURCE_DIR}/ADT/hash.c
-  ${LIB_SOURCE_DIR}/ArgParser/arg_parser.c
-  ${LIB_SOURCE_DIR}/ArgParser/debug_action.c
-  ${LIB_SOURCE_DIR}/ArgParser/xflag.c
-  )

and changes a few more things accordingly.

The idea of SHARED_SOURCES is to have the same source files compiled with different macro definitions. For this reason, the source files in SHARED_SOURCES cannot be shipped normally, as a static library.

But the purpose above does not apply to the argument parsing functions - they are universal. Therefore, this PR is taking them out of the SHARED_SOURCES.

@dmikushin
Copy link
Contributor Author

Need something extra on Windows:

lld-link: error: undefined symbol: flg
lld-link: error: undefined symbol: gbl
lld-link: error: undefined symbol: version

void bjunk(void *p, BIGUINT64 n);
#endif
#include "mall.h"
#include "listing.h"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we avoid including these headers within gbldefs.h, and instead include them in the .c or .cpp files that actually need the function declarations?

@@ -19,7 +19,7 @@ set(SOURCES
dtypeutl.cpp
fenddf.cpp
ilmutil.cpp
listing.cpp
listing.c
Copy link
Collaborator

Choose a reason for hiding this comment

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

This rename doesn't seem necessary at this point. In a future PR, perhaps we could move listing.c and listing.cpp from under tools/flang1/flang1exe/ and tools/flang2/flang2exe/, and merge them into one file under tools/shared/.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think I did this to come up with a proper name mangling and resolve link errors.

@bryanpkc
Copy link
Collaborator

Will you fix the Windows build failure as well?

@dmikushin
Copy link
Contributor Author

dmikushin commented Jul 11, 2023

I don't have a Windows builder yet, but I'm looking forward to getting it!

Currently, we are still discussing with you the enablement of Linux builds through Docker. How could I encourage you to have them, or accept mine? This is related, because I'm not able to use the CI and develop in it.

Copy link
Collaborator

@pawosm-arm pawosm-arm left a comment

Choose a reason for hiding this comment

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

I wouldn't do that. The original authors wanted to decouple these two as so they wouldn't be stopped with improving flang2 by the anchors deeply rooted in flang1 (and e.g. making flang2 compiled with a C++ compiler (versus C compiler) was one of the means for achieving such improvement). Some duplication was inevitable. This commit goes against that tide and restores the coupling.

@bryanpkc
Copy link
Collaborator

Closing the PR as it will not be accepted as-is.

@bryanpkc bryanpkc closed this Oct 18, 2023
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.

3 participants