Makefile experts, unite!

Phobos' posix.mak offers the ability to only run unittests for one module: make std/range/primitives.test BUILD=debug -j8 ... or package: make std/range.test BUILD=debug -j8 It runs module tests in parallel and everything. This is definitely awesome. But say I misspell things by using a dot instead of the slash: make std.range.test BUILD=debug -j8 Instead of an error, I get a no-op result that looks like success. How can that situation be converted to an error? Thanks, Andrei

Andrei Alexandrescu wrote: > Phobos' posix.mak offers the ability to only run unittests for one module: > > make std/range/primitives.test BUILD=debug -j8 > > ... or package: > > make std/range.test BUILD=debug -j8 > > It runs module tests in parallel and everything. This is definitely awesome. But say I misspell things by using a dot instead of the slash: > > make std.range.test BUILD=debug -j8 > > Instead of an error, I get a no-op result that looks like success. How can that situation be converted to an error? maybe by creating phony targets with such names?

June 11, 2017

Re: Makefile experts, unite!

Posted by Guillaume Boucher
in reply to Andrei Alexandrescu

Permalink

Guillaume Boucher

Posted in reply to Andrei Alexandrescu

Permalink

On Sunday, 11 June 2017 at 19:17:36 UTC, Andrei Alexandrescu wrote:
> Instead of an error, I get a no-op result that looks like success. How can that situation be converted to an error?

That makefile target is poorly written.

It was probably intended to have a dependency on the directory itself, so by adding "%/" to the pattern it correctly produces an error (since std.algorithm.d doesn't exist):

%.test : $(LIB) %/
        ...

To allow for your case, just add this line:

std.%.test : std/%.test


While that should work (at least for the first level), it still is very poorly written.  It doesn't use the white-listed modules/packages despite the rest of the makefile seems to use that fairly consistently.

I would replace all the ".test" targets with the following code:

# Target for quickly running a single unittest (using static phobos library).
# For example: "make std/algorithm/mutation.test"
# The mktemp business is needed so .o files don't clash in concurrent unittesting.
$(addsuffix .test,$(D_MODULES)): %.test : %.d $(LIB)
        T=`mktemp -d /tmp/.dmd-run-test.XXXXXX` &&                                                              \
          (                                                                                                     \
            $(DMD) -od$$T $(DFLAGS) -main -unittest $(LIB) -defaultlib= -debuglib= $(LINKDL) -cov -run $< ;     \
            RET=$$? ; rm -rf $$T ; exit $$RET                                                                   \
          )

# Target for quickly unittesting all modules and packages within a package,
# transitively. For example: "make std/algorithm.test"
define PACKAGETEST_template
$(1).test: $$(patsubst %,$(1)/%.test,$$(PACKAGE_$(subst /,_,$(1))))
endef
$(foreach package,$(STD_PACKAGES),$(eval $(call PACKAGETEST_template,$(package))))

# Target for quickly unittesting all modules and packages by using dot as a separator.
# For example: "make std.algorithm.sorting.test"
define MODULESYNTAXTEST_template
$(subst /,.,$(1)).test : $(1).test
endef
$(foreach module,$(STD_PACKAGES) $(D_MODULES),$(eval $(call MODULESYNTAXTEST_template,$(module))))


(I'm not going to make a pull request though.)

On 06/11/2017 12:27 PM, ketmar wrote: > p.s.: or replacing make-based build system with D-based. as we need > working D compiler to compile dmd anyway, i see no reason to not use it > more. I had the pleasure of working with Eyal Lotem, main author of buildsome. The buildsome team are aware of all pitfalls of all build systems and offer build*some* as an awe*some* ;) and correct build system: http://buildsome.github.io/buildsome/ Ali

Ali Çehreli wrote: > On 06/11/2017 12:27 PM, ketmar wrote: > >> p.s.: or replacing make-based build system with D-based. as we need >> working D compiler to compile dmd anyway, i see no reason to not use it >> more. > > I had the pleasure of working with Eyal Lotem, main author of buildsome. The buildsome team are aware of all pitfalls of all build systems and offer build*some* as an awe*some* ;) and correct build system: > > http://buildsome.github.io/buildsome/ haskell? no, thanks. sorry.

On Sunday, June 11, 2017 16:47:30 Ali Çehreli via Digitalmars-d wrote: > On 06/11/2017 12:27 PM, ketmar wrote: > > p.s.: or replacing make-based build system with D-based. as we need > > working D compiler to compile dmd anyway, i see no reason to not use it > > more. > > I had the pleasure of working with Eyal Lotem, main author of buildsome. The buildsome team are aware of all pitfalls of all build systems and offer build*some* as an awe*some* ;) and correct build system: > > http://buildsome.github.io/buildsome/ Atila did some work to get dmd, druntime, phobos, etc. building with reggae/dub, and I _think_ that he had it all working. As I understand it, the main barrier to switching to it officially was political. A number of us would _love_ to see the makefiles killed off, and there's really no technical barrier to doing so. It's really a question of convincing folks like Walter, Andrei, and Martin, and I get the impression that to an extent, there's an attitude of not wanting to mess with what's working (though I dispute that it works all that well from a maintenance perspective). It's certainly a pain to edit the makefiles though, and I think that we'd be far better off in the long run if we switched to something like reggae - and since reggae is written in D and uses dub, we'd be dogfooding our own stuff in the process. - Jonathan M Davis

On Sunday, 11 June 2017 at 23:47:30 UTC, Ali Çehreli wrote: > > I had the pleasure of working with Eyal Lotem, main author of buildsome. The buildsome team are aware of all pitfalls of all build systems and offer build*some* as an awe*some* ;) and correct build system: > > http://buildsome.github.io/buildsome/ Very interesting! The selling points, to me, are: 1) the automatic dependency detection through filesystem hooks 2) recipes also are dependencies 3) the genericity/low-level. I believe build systems should let me define my own abstractions, instead of trying to define for me what an "executable" or a "static library" should be. - Make has 3) - Ninja has 2), 3) - tup and buildsome have 1), 2), 3) However, buildsome also seems to have a (simplified) make-like syntax. Why did they have to write it in Haskell, for god's sake!

Jonathan M Davis wrote: > It's certainly a pain to edit the makefiles though and don't forget those Great Copying Lists to copy modules. forgetting to include module in one of the lists was happened before, not once or twice...

On Monday, 12 June 2017 at 06:30:16 UTC, ketmar wrote: > Jonathan M Davis wrote: > >> It's certainly a pain to edit the makefiles though > > and don't forget those Great Copying Lists to copy modules. forgetting to include module in one of the lists was happened before, not once or twice... I don't get it, could you please show an example?

Forums