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

Automake buildsystem? #29

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

Conversation

ndim
Copy link
Member

@ndim ndim commented Jan 28, 2022

Even though building with an Automake based buildsystem takes a lot more time, it is still convenient to follow standard conventions like having a configure script to run.

Not sure I really want to switch. The current GNUmakefile is quite neat with its installing only what actually is actually necessary and stuff.

@ndim ndim force-pushed the automake-buildsystem branch 7 times, most recently from 97fb6ad to 0576111 Compare January 31, 2022 19:01
@ndim ndim changed the title Automake buildsystem Automake buildsystem? Feb 1, 2022
@ndim ndim force-pushed the automake-buildsystem branch 2 times, most recently from ad6ac85 to 9e6fa58 Compare July 22, 2022 22:44
@ndim ndim force-pushed the automake-buildsystem branch 10 times, most recently from 9690fc5 to 00348b4 Compare October 3, 2022 05:13
Change buildsystem from custom GNUmakefile to standard automake.

This allows builds with the standard invocation of

    autoreconf -if      # if not building from dist tarball
    ./configure
    make
    sudo make install

The configure.ac is based on the output of autoscan, with quite a
bit of manual work added on top.

Uses the ancient serial-tests test harness in order to re-use the
existing run-tests script.
@ndim ndim force-pushed the automake-buildsystem branch from 00348b4 to 0f56aa3 Compare October 16, 2022 13:09
ndim added 2 commits October 16, 2022 23:36
Update Doxygen.in file to doxygen 1.9.5, and have configure script
check the doxygen version found before the Makefile.am uses it.
@3x380V
Copy link

3x380V commented Apr 24, 2024

Using AC_LINK_IFELSE would be actually useful to find out whenever beep needs to be linked with -latomic. It's the case with at least armv5te target. Either that or move to event loop (your other draft) as it removes the use of volatile sig_atomic_t global_abort.

@3x380V
Copy link

3x380V commented Apr 26, 2024

Hmm, above is caused by address sanitizer which requires both -lubsan and -latomic. There is nothing to handle additional libraries currently, so I'll just provide local.mk to disable all that additional checks. However there are few nits to fix and I will open PR for them. You may disregard my comments now.

@ndim
Copy link
Member Author

ndim commented Apr 26, 2024

beep does not use any symbols regarding atomic stuff which might be supplied by a library. beep only uses the sig_atomic_t type at compile time, so I do not see how linking any library to beep would make sense.

Besides, what system using a armv5te target CPU can make use of beep? It cannot have classic PC speaker hardware, so beep would at least need to add a well known device name to look for.

@ndim
Copy link
Member Author

ndim commented Apr 26, 2024

So... if I understand you correctly, you basically want to have a local.mk containing

CFLAGS = -fsanitize=undefined
LDADD = -lubsan -latomic

but only add the LDADD part for architecture/compiler/libc environments where it is actually needed?

@3x380V
Copy link

3x380V commented May 10, 2024

You may see actual linking error and explanation here: https://lore.ptxdist.org/ptxdist/ZjNw3VmNCgGpJwsq@lenoch/T/#m080d02abdd4a8f7432d73fa5fedfc26f949cdcf4
Solved this way: https://git.pengutronix.de/cgit/ptxdist/commit/?id=0b9fb169815fdea1de4901ce0434a048affbff39
While GNUMakefile could certainly use something like Busybox' scripts/trylink I'm considering that an overkill, so no action needed on beep part :)

Also note kernel contains drivers/input/misc/gpio-beeper.c and drivers/input/misc/pwm-beeper.c both being perfectly useable with beep, so many thanks for still maintaining it!

@ndim
Copy link
Member Author

ndim commented May 10, 2024

Also note kernel contains drivers/input/misc/gpio-beeper.c and drivers/input/misc/pwm-beeper.c both being perfectly useable with beep, so many thanks for still maintaining it!

If you have an idea where to find the well-known device names for those hardware devices, please let me know so I can add them to beep.

At this time, beep only knows to look for the PC speaker device /dev/input/by-path/platform-pcspkr-event-spkr.

I will take a look at the build stuff later.

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.

2 participants