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

Further improvement of makefiles #114

Open
GoogleCodeExporter opened this issue Aug 12, 2015 · 8 comments
Open

Further improvement of makefiles #114

GoogleCodeExporter opened this issue Aug 12, 2015 · 8 comments
Labels
DevOps Testing, deployment, automation pri-Medium Worth assigning to a milestone usability Makes using code more convenient
Milestone

Comments

@GoogleCodeExporter
Copy link

There are a few ideas:
1) It would be nice to have compilation goals like 'install' and 'dist'. So 
that it would look more standard from a GNU-point of view.
2) It is not clear whether makefiles will work if executed from a different 
directory. Should be tested.
3) Inclusion of dependencies causes make to scan some makefiles twice, 
including variable processing (e.g. in mpi/Makefile). It is logical to separate 
this two processes completely.

Original issue reported on code.google.com by yurkin on 6 Sep 2010 at 6:20

@GoogleCodeExporter GoogleCodeExporter added OpSys-All usability Makes using code more convenient comp-Scripts Related to Makefiles, wrappers, developer and testing scripts pri-Low Kept mostly for reference labels Aug 12, 2015
@myurkin myurkin added feature Allows new functionality and removed Type-Enhancement labels Aug 13, 2015
@myurkin myurkin self-assigned this Nov 12, 2015
@myurkin
Copy link
Member

myurkin commented Sep 13, 2018

A related idea is to use configure scripts as was discussed in #81

@myurkin
Copy link
Member

myurkin commented Oct 14, 2020

Another related idea is to create packages for ADDA (automatically compiled), for which GitHub has recently added internal support.

@myurkin
Copy link
Member

myurkin commented Nov 14, 2020

A related (potential) idea is to use CMake instead of configure - not sure what is better.

@myurkin myurkin added pri-Medium Worth assigning to a milestone and removed pri-Low Kept mostly for reference labels Dec 2, 2020
@myurkin myurkin added this to the 1.5 milestone Dec 2, 2020
@myurkin
Copy link
Member

myurkin commented Mar 5, 2021

Use of CMake is a must for conveniently using other toolchains on Windows, like Intel Compiler on top of Visual Studio. If we do it ourselves, we need to:

  • change some compilation options (i.e. -QMD and -Qstd=c99 instead of -MD and -std=c99, respectively)
  • use .obj extension instead of .o for object files
  • rework specification of paths to libraries (e.g. LIB environmental variable instead of -L... flags) or give full path to libraries together with their names.
  • specify full library file name (*.lib) instead of -l... flags
  • if compiling Fortran sources, the calling names of corresponding functions from in C files need to be changed from function_ to FUNCTION (this can be made by macros) or using ISO_C_BINDING inside Fortran sources.

I have managed to perform such simulation in the simplest seq mode using a special batch file src/iw_compile.bat, but it would be hard to enable this inside the current Makefile keeping compatibility with all existing modes.

Still, I do not see any immediate value in supporting this toolchain on Windows.

@myurkin myurkin removed their assignment Apr 24, 2021
@myurkin myurkin modified the milestones: 1.5, 1.6 Apr 24, 2021
@myurkin myurkin added DevOps Testing, deployment, automation and removed feature Allows new functionality comp-Scripts Related to Makefiles, wrappers, developer and testing scripts labels Mar 18, 2022
@myurkin myurkin mentioned this issue Mar 21, 2022
@myurkin
Copy link
Member

myurkin commented Jul 5, 2024

Here are minimalistic examples of CMake files to compile ADDA (seq and ocl modes) with static linking of Fortran libraries, contributed by Michel Gross. While they are definitely simpler than basic makefiles, it is still not clear, whether CMake can (and how easy) incorporate all the complexity (and various modes) of current ADDA makefiles.

cmakelists_fortran.txt
CMakeLists_ocl.txt
CMakeLists_adda.txt

@Argencle
Copy link
Contributor

To improve the organisation and maintainability of the project, I propose to standardise the directory structure by adding the following folders at some point:

  1. bin/:

    • Stores final executables.
  2. build/:

    • Contains intermediate build files.
    • Easily cleaned up and added to .gitignore.

@myurkin myurkin removed this from the 1.7 milestone Feb 24, 2025
@myurkin myurkin added this to the 1.6 milestone Feb 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DevOps Testing, deployment, automation pri-Medium Worth assigning to a milestone usability Makes using code more convenient
Projects
None yet
Development

No branches or pull requests

3 participants