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

Fix out-of-tree builds generating netcdf_json.h and netcdf_proplist.h #3060

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

Conversation

opoplawski
Copy link
Contributor

Without this, build/include/netcdf_json.h and build/include_netcdf_proplist.h simply contain the initial #ifdev line.

@DennisHeimbigner
Copy link
Collaborator

I rebuilt these constructions as` part of my repo:

https://github.com/DennisHeimbigner/netcdf-c branch v3plug.tmp

Any chance you can look to see if my version solves your problem?

@DennisHeimbigner
Copy link
Collaborator

To simplify my query. Here is the Automake code for building netcdf_json.h and netcdf_proplist.h

# netcdf_json.h is constructed as a header-only file for use by
# nczarr code wrappers in the plugin directory. It is
# constructed by joining libdispatch/ncjson.c with
# include/ncjson.h.  Additionally all the entry points are
# marked with a macro (OPTSTATIC) that marks the entry point as
# static inside netcdf_json.h.	This is an ugly hack to avoid
# having to reference libnetcdf in the nczarr code wrappers.

# Give the recipe for building netcdf_json.h
netcdf_json.h: ${top_srcdir}/libdispatch/ncjson.c ${top_srcdir}/include/ncjson.h
	rm -fr ${srcdir}/netcdf_json.h
	cat ${srcdir}/ncjson.h \
	    | sed -e '/!NCJSON_H/d' \
    	    | sed -e 's/NCJSON_H/NETCDF_JSON_H/' \
	    >> ${srcdir}/netcdf_json.h
	cat ${srcdir}/../libdispatch/ncjson.c | sed -e '/ncjson.h/d' >> ${srcdir}/netcdf_json.h
	echo '#endif /*NETCDF_JSON_H*/' >> ${srcdir}/netcdf_json.h

# netcdf_proplist is analogous to netcdf_json but, of course, using libdispatch/ncproplist.c and include/ncproplist.h
# Give the recipe for building netcdf_proplist.h. Basically same as for netcdf_json.h
netcdf_proplist.h: ${top_srcdir}/libdispatch/ncproplist.c ${top_srcdir}/include/ncproplist.h
	rm -fr ${srcdir}/netcdf_proplist.h
	cat ${srcdir}/ncproplist.h \
	    | sed -e '/!NCPROPLIST_H/d' \
    	    | sed -e 's/NCPROPLIST_H/NETCDF_PROPLIST_H/' \
	    >> ${srcdir}/netcdf_proplist.h
	cat ${srcdir}/../libdispatch/ncproplist.c | sed -e '/ncproplist.h/d' >> ${srcdir}/netcdf_proplist.h
	echo '#endif /*NETCDF_PROPLIST_H*/' >> ${srcdir}/netcdf_proplist.h

and the same code for CMakeLists.txt.

# Built source: netcdf_json.h
file(READ ncjson.h JSONH0)
STRING(REPLACE "NCJSON_H" "NETCDF_JSON_H" JSONH1 "${JSONH0}")
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/netcdf_json.h "${JSONH1}")
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/netcdf_json.h "#ifdef NETCDF_JSON_H\n")
file(READ ${CMAKE_SOURCE_DIR}/libdispatch/ncjson.c JSONC0)
STRING(REGEX REPLACE "#include[ ]+\"ncjson.h\"" "" JSONC1 "${JSONC0}")
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/netcdf_json.h "${JSONC1}")
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/netcdf_json.h "#endif /*NETCDF_JSON_H*/\n")

# Built source: netcdf_proplist.h
file(READ ncproplist.h PLISTH0)
STRING(REPLACE "NCPROPLIST_H" "NETCDF_PROPLIST_H" PLISTH1 "${PLISTH0}")
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/netcdf_proplist.h "${PLISTH1}")
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/netcdf_proplist.h "#ifdef NETCDF_PROPLIST_H\n")
file(READ ${CMAKE_SOURCE_DIR}/libdispatch/ncproplist.c PLISTC0)
STRING(REGEX REPLACE "#include[ ]+\"ncproplist.h\"" "" PLISTC1 "${PLISTC0}")
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/netcdf_proplist.h "${PLISTC1}")
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/netcdf_proplist.h "#endif /*NETCDF_PROPLIST_H*/\n")

@opoplawski
Copy link
Contributor Author

I would argue that you shouldn't be modifying anything in ${srcdir}, and instead use ${builddir}. This is what the cmake code is doing when it specifies ${CMAKE_CURRENT_BINARY_DIR}.

@opoplawski
Copy link
Contributor Author

Also added a fix for another out-of-tree build issue with a test.

@DennisHeimbigner
Copy link
Collaborator

I see. And you are correct.

@WardF WardF self-assigned this Dec 19, 2024
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